CVE-2024-36111
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:LSummary
CVE-2024-36111 is a medium-severity Improper Restriction of Security Token Assignment (CWE-1259) vulnerability. Its CVSS base score is 6.3 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Access Token Manipulation (T1134); ranked in the top 6% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-25 (Reference Monitor) and AC-3 (Access Enforcement) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
KubePi, an open-source Kubernetes management panel, contains a JWT token verification flaw in versions 1.6.3 through 1.7.x. The default configuration file ships with an empty JWT signing key; although startup logic attempts to generate a random 32-byte replacement when the empty value is detected, the verification path continues to use the empty key, allowing crafted tokens to be accepted as valid.
An attacker with network access to the KubePi instance can therefore create a JWT signed with an empty key, bypass all authentication checks, and obtain full administrative control of the backend. The CVSS 6.3 rating reflects network attack vector, low complexity, and limited privileges required, resulting in confidentiality, integrity, and availability impacts within the application.
The project advisory GHSA-8q5r-cvcw-4wx7 states that the issue is resolved in version 1.8.0; administrators should upgrade immediately and verify that the JWT key field in the configuration file contains a non-empty value after deployment. The associated EPSS score of 0.61 shows no material post-disclosure increase.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-35886
Vulnerability Data
KubePi is a K8s panel. Starting in version 1.6.3 and prior to version 1.8.0, there is a defect in the KubePi JWT token verification. The JWT key in the default configuration file is empty. Although a random 32-bit string will…
more
be generated to overwrite the key in the configuration file when the key is detected to be empty in the configuration file reading logic, the key is empty during actual verification. Using an empty key to generate a JWT token can bypass the login verification and directly take over the back end. Version 1.8.0 contains a patch for this issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
A tamperproof reference monitor ensures security tokens cannot be improperly assigned or altered outside policy.
Access enforcement directly requires that security tokens used for authorization decisions are protected from unauthorized assignment or modification.
Isolating security functions from non-security functions reduces the attack surface for tampering with token assignment logic.
Security attributes (tokens) must be associated and maintained with subjects/objects, which structurally prevents improper assignment or lack of protection.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Proper definition and enforcement of authorizations directly addresses improper security token restrictions.
Pre-acquisition hardware integrity checks can detect flawed token protection mechanisms before deployment.
Logical access protections can prevent exploitation of improperly assigned hardware security tokens.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Privileged access rights help ensure only authorized processes can assign or modify tokens.
Security testing can detect improper token assignment but does not prevent it at design time.
Information access restriction directly limits which entities can obtain or use security tokens.
Secure architecture principles can guide token protection mechanisms but do not enforce assignment rules.
Secure coding practices reduce the likelihood of token-assignment bugs but do not define the policy.
Cryptography can protect token confidentiality but does not address improper assignment logic.