Critical CVE-2025-32445 Vulnerability in Argo Events Scores CVSS 10

This security issue gives an attacker the ability to exploit a vulnerability in Argo Events, enabling users with permission to create or modify EventSource and Sensor custom resources to gain privileged access to the host system and cluster, bypassing direct administrative privileges. The following protection guardrails can further prevent the following steps an attacker can take: When an attacker crafts a malicious custom resource to specify container properties like privileged: true and add SYS_ADMIN capabilities, Container Capability Control helps prevent the pod from being created with these escalated privileges by enforcing policies that disallow such settings, thereby blocking the initial privilege escalation attempt. Should an attacker somehow gain a privileged pod, they might then attempt to execute new, unauthorized binaries or scripts within this compromised container, such as tools to access the host system or install persistence mechanisms like a reverse shell; Container Drift Protection (Binaries & Scripts) helps prevent this by blocking the execution of any executables not part of the original container image, limiting the attacker's ability to run custom tools. Furthermore, if the attacker tries to run commands or tools, for instance, to inspect the host's process list using ps or crictl, or install network sniffing tools like tcpdump from non-standard or disallowed locations within the pod or the mounted host filesystem, Process Path Exec Allow helps prevent such execution by enforcing an allowlist for executable paths, thus restricting the attacker's command execution capabilities. If the attacker, having gained host root equivalent access (e.g., via chroot), uses nsenter to enter other containers' namespaces then the Namespace Execution Guard blocks host root from using nsenter to enter container namespaces. Finally, if the attacker attempts to load malicious shared libraries from untrusted paths within the compromised pod or a subsequently accessed tenant's container to execute arbitrary code, Library Load Path Allow helps prevent this by blocking library loading from non-allowed paths, hindering code injection attempts.

• T1199: Trusted Relationship: The article describes a vulnerability in Argo Events that allows users with permission to create or modify EventSource and Sensor custom resources to gain privileged access to the host system and cluster. This involves exploiting the handling of EventSource and Sensor CRs by customizing container properties, which is a form of exploitation of a trusted relationship. The attacker can gain elevated privileges by setting the spec.template.container with properties like privileged: true and adding the SYS_ADMIN capability, thus escalating their privileges. This aligns with the MITRE ATT&CK technique for exploiting trusted relationships, where an attacker abuses a legitimate relationship to gain elevated access.
• T1068: Exploitation for Privilege Escalation: The article details how the vulnerability in Argo Events can be exploited by modifying the spec.template.container section of EventSource and Sensor CRs to gain privileged access to the cluster host. This includes settings such as privileged: true and adding the SYS_ADMIN capability, which allow the attacker to escalate their privileges within the Kubernetes environment. This matches the MITRE ATT&CK technique for container and system privilege escalation, where an attacker exploits a weakness to gain higher privileges.
• T1005: Data from Local System: The vulnerability allows an attacker to mount the host's root filesystem by exploiting the customization capabilities of the spec.template.container. This action provides the attacker with access to the host system's filesystem, effectively allowing them to break tenant isolation and access other tenants' data. This corresponds to the MITRE ATT&CK technique for data from local system, where an attacker gains access to and exfiltrates data from the local filesystem.
• T1562: Impair Defenses: By exploiting the vulnerability, the attacker can bypass security models, including RBAC restrictions and Pod Security Policies/Standards. This indicates a circumvention of access controls, which is a core concept in the MITRE ATT&CK framework for access control bypass. This involves exploiting vulnerabilities or misconfigurations to gain access to resources that should be restricted.

F1: Exploitation of CVE-2025-32445 in Argo Events by a user with permissions to create/modify EventSource or Sensor custom resources (CRs) to gain privileged access to the host system and Kubernetes cluster.

• Attacker gains or possesses permissions to create/modify EventSource and Sensor custom resources within the target Kubernetes cluster. (Cited from: "a user with permission to create/modify EventSource and Sensor custom resources can gain privileged access to the host system and cluster")
• Attacker crafts a malicious EventSource or Sensor CR. (Cited from: "a user with permission to create/modify EventSource and Sensor custom resources can gain privileged access", "The advisory provides a sample EventSource configuration that demonstrates how this vulnerability can be exploited.")
• Within the malicious CR, the attacker customizes the spec.template and specifically the spec.template.container section. (Cited from: "EventSource and Sensor CRs can be customized with spec.template and spec.template.container")
• In the spec.template.container section, the attacker specifies malicious container properties. These include setting privileged: true, adding the SYS_ADMIN capability, and defining a volumeMount to mount the host's root filesystem (e.g., /) into the pod. (Cited from: "allows users to specify various container properties, such as command, args, securityContext, and volumeMount", "The example includes settings like privileged: true, adding the SYS_ADMIN capability, and mounting the host’s root filesystem.")
  • BR-47: Container Capability Control - This mechanism is applicable because the attacker is attempting to escalate privileges by setting privileged: true and adding the SYS_ADMIN capability. BR-47 is designed to enforce specific capabilities for containers, overriding defaults and potentially preventing the assignment of these high-privilege capabilities if they violate policy. The LLM rule matches as the attack involves "privileged containers" and "Kubernetes capabilities".
  • BR-66: Host FS Mount Control - This mechanism is applicable because the attacker is defining a volumeMount to mount the host's root filesystem. BR-66 enforces an allow list for host file system mounts and could deny this operation if mounting the root filesystem is not explicitly permitted by policy. The LLM rule matches as the attack involves a "file system mount" (host root FS).
  • BR-67: Container Root User Control - This mechanism is applicable because setting privileged: true typically results in the container's processes running as root. BR-67 detects and prevents processes running as root within a container (except for the designated init process). If the attacker's specified command/args result in a non-init root process, this mechanism would apply when the pod attempts to run. The LLM rule matches due to "process running as root within a container" and "privilege escalation within containers".
• Attacker applies the malicious EventSource or Sensor CR to the Kubernetes cluster.
• Argo Events processes the CR, and due to the vulnerability, the specified malicious container settings (privileged: true, SYS_ADMIN capability, host root mount) are applied to the EventSource or Sensor pod that gets created. (Cited from: "Due to the code logic, these specifications are applied to the EventSource or Sensor pod.")
  • BR-47: Container Capability Control - This mechanism applies at the point the pod is created with the malicious settings. It would enforce policies to prevent the pod from gaining privileged: true status or the SYS_ADMIN capability if these are disallowed. The LLM rule matches due to "privileged containers" and "Kubernetes capabilities".
  • BR-66: Host FS Mount Control - This mechanism applies as the pod attempts to mount the host root filesystem during its creation/startup. BR-66 would block this mount if the host's root filesystem is not on the configured allow list. The LLM rule matches as it involves a "container mount" of a host filesystem.
  • BR-67: Container Root User Control - This mechanism applies when the created pod starts running processes. If the container attempts to run processes as root (beyond the allowed init process) due to the privileged: true setting, BR-67 would detect and potentially block this. The LLM rule matches as it involves "process running as root within a container".
• The attacker's pod now runs with high privileges on the underlying Kubernetes node, with access to the entire host filesystem.
  • BR-67: Container Root User Control - If processes within this pod run as root (and are not the designated init process for the container namespace), this mechanism would apply to detect and potentially block these root processes. The privileged: true setting makes it highly likely that the main process runs as root. The LLM rule for BR-67 matches due to "process running as root within a container" and the context of privilege escalation.
• Attacker executes commands within this privileged pod to access and control the host system and potentially the wider cluster. (Cited from: "By carefully crafting the template.container section, an attacker can gain privileged access to the cluster host.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If the attacker executes new binaries or scripts within the pod that were not part of its original image (e.g., downloaded tools or custom scripts), this mechanism would block their execution. The LLM rule applies if the attack allows running OS level commands within the container.
  • BR-88: Process Path Exec Allow - If the attacker executes commands from paths within the pod (or the mounted host filesystem via the pod) that are not on the pre-defined allowlist, this mechanism would block the execution. The LLM rule applies if execution occurs from a non-standard or disallowed location.
  • BR-90: Process Exec Deny - If the attacker attempts to execute specific denied processes (e.g., default-denied nc, wget, curl, or other tools added to a deny list) from within the pod, this mechanism would block their execution. The LLM rule applies if execution of a denied program name or suffix occurs.
  • BR-91: Sensitive File Access - If the attacker attempts to access sensitive files on the mounted host filesystem (e.g., /etc/shadow on the host, SSH keys, credentials), this mechanism would detect or block such access if these files/paths are configured as sensitive. The LLM rule for BR-91 matches due to potential access to "sensitive files" or "credentials in files".
  • BR-78: Host Setuid File Protection - If the attacker, leveraging the mounted host filesystem, attempts to write to or modify setuid files on the host from within the container to escalate privileges further on the host, this mechanism would apply. The LLM rule for BR-78 matches due to potential "unauthorized file modification" of "setuid files" from a container.
  • BR-89: Library Load Path Allow - If the attacker attempts to load shared libraries from untrusted paths within the pod or on the mounted host filesystem to execute malicious code, this mechanism would block the loading of libraries from non-allowed paths. The LLM rule applies if library loading from an untrusted path occurs.
  • BR-86: PTrace Protection - If the attacker uses ptrace from within the privileged pod to inspect or manipulate other processes on the host or in other containers on the same node, this mechanism would intercept and potentially block unauthorized ptrace calls. The LLM rule for BR-86 matches if ptrace is used for unauthorized memory access or process injection.
• This leads to severe consequences such as breaking tenant isolation, non-admin users gaining host/cluster access, access to other tenants’ data, bypassing security models (RBAC, Pod Security Policies/Standards), and complete compromise of the host system. (Cited from: "Tenant isolation being broken Non-admin users gaining host/cluster access Access to other tenants’ data Bypassing security models, including RBAC restrictions and Pod Security Policies/Standards Compromise of the host system")