CVE-2023-22463: KubePi hard-coded JWT signing key allows token forgery

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 19 September 2026. Confidence: high.

critical priorityCVSS 9.8 with no authentication or interaction required, public exploit material, and full admin and cluster takeover impact.

What it is

KubePi through 1.6.2 hard-codes the JWT signing key in session.go, so every deployment shares the same key. Anyone who knows that key can forge a JWT and impersonate an administrator. The flaw is fixed in 1.6.3, where the key is read from app.yml or randomly generated if left blank.

Impact

An attacker gains full administrative control of the KubePi panel and can then take over the Kubernetes cluster it manages.

Attack surface

Reachable over the network via the JWT authentication path with no authentication or user interaction required, per the CVSS vector AV:N/AC:L/PR:N/UI:N.

Exploitation

Not listed in CISA KEV, but EPSS is 0.69667 (99.3rd percentile) and the GitHub advisory is tagged Exploit, indicating public exploit material exists.

What to do

• Upgrade KubePi to 1.6.3 or later immediately; no workaround exists besides upgrading.
• After upgrading, set a strong unique JWT key in app.yml rather than leaving it blank.
• Rotate any credentials or tokens that may have been exposed while running an affected version.
• Restrict network access to the KubePi panel to trusted management networks only.

Detection

• Monitor KubePi authentication logs for admin sessions originating from unexpected IP addresses or user agents.
• Alert on JWT validation failures or tokens signed with the known hard-coded key.
• Audit Kubernetes API activity for actions performed by KubePi service accounts outside normal administrative patterns.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.