CVE-2024-36533
📋 TL;DR
This vulnerability in volcano v1.8.2 allows attackers to access service account tokens due to insecure permissions. Attackers can use these tokens to escalate privileges and access sensitive data within Kubernetes clusters. Organizations running vulnerable volcano versions are affected.
💻 Affected Systems
- volcano
⚠️ 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
Full cluster compromise allowing attackers to access all resources, deploy malicious workloads, exfiltrate sensitive data, and potentially pivot to other systems.
Likely Case
Privilege escalation within the cluster allowing unauthorized access to sensitive workloads, configuration data, and service account privileges.
If Mitigated
Limited impact with proper network segmentation, RBAC restrictions, and service account token rotation policies in place.
🎯 Exploit Status
Exploitation requires initial access to the cluster but is straightforward once inside. The gist references provide technical details.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: v1.8.3 or later
Vendor Advisory: https://github.com/volcano-sh/volcano
Restart Required: Yes
Instructions:
1. Backup current volcano configuration. 2. Update volcano to v1.8.3 or later using your package manager or container registry. 3. Restart volcano components. 4. Verify the update was successful.
🔧 Temporary Workarounds
Restrict Service Account Permissions
linuxApply least privilege principles to volcano service accounts using Kubernetes RBAC
kubectl create clusterrole volcano-restricted --verb=get,list,watch --resource=pods,services
kubectl create clusterrolebinding volcano-restricted-binding --clusterrole=volcano-restricted --serviceaccount=volcano-system:volcano-scheduler
Disable Automatic Service Account Token Mounting
linuxPrevent automatic mounting of service account tokens in volcano pods
kubectl patch deployment volcano-scheduler -n volcano-system --type='json' -p='[{"op": "add", "path": "/spec/template/spec/automountServiceAccountToken", "value": false}]'
🧯 If You Can't Patch
- Implement network policies to restrict volcano component communications
- Regularly rotate service account tokens and monitor for unauthorized usage
🔍 How to Verify
Check if Vulnerable:
Check volcano version: kubectl get deployment volcano-scheduler -n volcano-system -o jsonpath='{.spec.template.spec.containers[0].image}'Check Version:
kubectl get deployment volcano-scheduler -n volcano-system -o jsonpath='{.spec.template.spec.containers[0].image}' | grep -o 'v[0-9.]*'Verify Fix Applied:
Verify version is v1.8.3 or later and check service account token permissions in volcano pods📡 Detection & Monitoring
Log Indicators:
- Unauthorized access attempts to volcano service account tokens
- Unusual API calls from volcano service accounts
- Privilege escalation events in audit logs
Network Indicators:
- Unexpected outbound connections from volcano pods
- Traffic to external endpoints using service account tokens
SIEM Query:
source="kubernetes" ("volcano" AND ("serviceaccount" OR "token")) AND (action="create" OR action="get")