CVE-2024-36111
📋 TL;DR
KubePi versions 1.6.3 through 1.7.x have a critical JWT authentication bypass vulnerability. Attackers can forge valid JWT tokens using an empty signing key to bypass login verification and gain unauthorized access to the Kubernetes management panel. This affects all deployments using default configurations.
💻 Affected Systems
- KubePi
⚠️ Manual Verification Required
This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.
Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).
🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.
- Review the CVE details at NVD
- Check vendor security advisories for your specific version
- Test if the vulnerability is exploitable in your environment
- Consider updating to the latest version as a precaution
⚠️ Risk & Real-World Impact
Worst Case
Complete compromise of the KubePi instance allowing attackers to manage Kubernetes clusters, deploy malicious workloads, access sensitive cluster data, and potentially pivot to other systems.
Likely Case
Unauthorized administrative access to KubePi panel leading to unauthorized Kubernetes operations, data exposure, and potential privilege escalation within the cluster.
If Mitigated
Limited impact with proper network segmentation and additional authentication layers, but still represents a significant authentication bypass.
🎯 Exploit Status
Exploitation requires no authentication and can be performed with simple JWT manipulation tools. The advisory includes technical details that facilitate exploitation.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 1.8.0
Vendor Advisory: https://github.com/1Panel-dev/KubePi/security/advisories/GHSA-8q5r-cvcw-4wx7
Restart Required: Yes
Instructions:
1. Backup current configuration and data. 2. Stop KubePi service. 3. Upgrade to version 1.8.0 using your deployment method (Docker, binary, etc.). 4. Verify the JWT key in configuration is properly set. 5. Restart KubePi service.
🔧 Temporary Workarounds
Manual JWT Key Configuration
allManually set a strong JWT signing key in the configuration file to override the empty default.
Edit KubePi configuration file and set 'jwt.key' to a secure random string (minimum 32 characters)
Restart KubePi service after configuration change
🧯 If You Can't Patch
- Immediately restrict network access to KubePi instances using firewall rules to only allow trusted IPs
- Implement additional authentication layer (reverse proxy with authentication, VPN, or network segmentation)
🔍 How to Verify
Check if Vulnerable:
Check KubePi version: if between 1.6.3 and 1.7.x, you are vulnerable. Also check configuration file for empty JWT key.Check Version:
Check KubePi web interface or deployment logs for version information, or inspect container/image tags if using Docker.Verify Fix Applied:
Verify version is 1.8.0 or higher, and confirm JWT key in configuration is a non-empty secure string.📡 Detection & Monitoring
Log Indicators:
- Unusual authentication patterns
- Successful logins without proper credentials
- JWT verification failures followed by successful access
Network Indicators:
- Unauthorized API calls to KubePi endpoints
- Traffic from unexpected sources to KubePi service
SIEM Query:
source="kubepi" AND (event="authentication_failure" OR event="jwt_verification_error") | stats count by src_ip