KubePi's Hardcoded Jwtsigkeys allows malicious actor to login with a forged JWT token
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.6.3
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 Nuclei template
- Exploitation: poc
- Automatable: yes
- Technical impact: total
Summary
KubePi is a k8s panel. The jwt authentication function of KubePi through version 1.6.2 uses hard-coded Jwtsigkeys, resulting in the same Jwtsigkeys for all online projects. This means that an attacker can forge any jwt token to take over the administrator account of any online project. Furthermore, they may use the administrator to take over the k8s cluster of the target enterprise. `session.go`, the use of hard-coded JwtSigKey, allows an attacker to use this value to forge jwt tokens arbitrarily. The JwtSigKey is confidential and should not be hard-coded in the code. The vulnerability has been fixed in 1.6.3. In the patch, JWT key is specified in app.yml. If the user leaves it blank, a random key will be used. There are no workarounds aside from upgrading.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: poc · Automatable: yes · Technical impact: total
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- KubeOperator KubePi
fixed in 1.6.3
- github.com/KubeOperator/kubepiGo
fixed in 1.6.3