CVE-2025-32445
📋 TL;DR
This CVE allows authenticated users with EventSource/Sensor CRUD permissions in Argo Events to escalate privileges by crafting malicious pod specifications, gaining full cluster and host access. It affects Kubernetes clusters running vulnerable Argo Events versions where users have these permissions. The vulnerability stems from insufficient validation of user-provided container specifications.
💻 Affected Systems
- Argo Events
⚠️ 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 attacker to execute arbitrary code on all nodes, exfiltrate sensitive data, deploy malicious workloads, and potentially pivot to other infrastructure.
Likely Case
Privilege escalation within the cluster leading to unauthorized access to sensitive workloads, secrets, and persistent storage.
If Mitigated
Limited impact if RBAC is properly configured to restrict EventSource/Sensor permissions to trusted users only.
🎯 Exploit Status
Exploitation requires authenticated access with appropriate RBAC permissions. The technique is straightforward for users familiar with Kubernetes pod specifications.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 1.9.6
Vendor Advisory: https://github.com/argoproj/argo-events/security/advisories/GHSA-hmp7-x699-cvhq
Restart Required: Yes
Instructions:
1. Backup your Argo Events configuration. 2. Update Argo Events to version 1.9.6 or later using your preferred deployment method (helm, kubectl, etc.). 3. Verify all EventSource and Sensor pods restart with the new version. 4. Test existing workflows to ensure compatibility.
🔧 Temporary Workarounds
RBAC Restriction
allRestrict create/update permissions for EventSource and Sensor CRDs to trusted administrators only.
kubectl edit clusterrole <argo-events-role>
kubectl edit role <argo-events-role> -n <namespace>
Admission Controller Validation
allUse OPA/Gatekeeper or Kyverno to validate EventSource/Sensor CRs and reject privileged container specifications.
🧯 If You Can't Patch
- Implement strict RBAC controls to limit EventSource/Sensor permissions to essential personnel only
- Deploy runtime security tools (Falco, Aqua, Sysdig) to detect and alert on privilege escalation attempts
🔍 How to Verify
Check if Vulnerable:
Check Argo Events controller version: kubectl get deployment -n argo-events argo-events-controller -o jsonpath='{.spec.template.spec.containers[0].image}'
Check Version:
kubectl get deployment -n argo-events argo-events-controller -o jsonpath='{.spec.template.spec.containers[0].image}' | grep -o 'v[0-9.]*'
Verify Fix Applied:
Confirm version is 1.9.6 or higher and test that privileged container specifications in EventSource/Sensor CRs are rejected
📡 Detection & Monitoring
Log Indicators:
- Unauthorized EventSource/Sensor creation/modification
- Privileged container creation in argo-events namespace
- Security context privilege escalation in pod logs
Network Indicators:
- Unexpected outbound connections from argo-events pods
- Cluster API calls from argo-events pods to sensitive endpoints
SIEM Query:
index=k8s (source="argo-events" OR pod_name="*argo-events*") ("privileged=true" OR "hostPID" OR "hostNetwork" OR "allowPrivilegeEscalation=true")