Privilege Escalation via podSpecPatch in Argo Workflows

Executive Summary

[{'type': 'paragraph', 'content': 'CVE-2026-31892 is a high-severity security bypass vulnerability in Argo Workflows, an open source container-native workflow engine for Kubernetes. It affects versions from 2.9.0 to before 3.7.11 and 4.0.0 to before 4.0.2.'}, {'type': 'paragraph', 'content': 'The vulnerability allows a user who can submit Workflows to bypass all security restrictions defined in an admin-approved WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This happens even when the controller is configured with templateReferencing: Strict mode, which is intended to restrict users to only admin-approved templates.'}, {'type': 'paragraph', 'content': "Technically, the Workflow spec merging logic prioritizes the podSpecPatch field over the referenced WorkflowTemplate's pod spec and applies it directly to the pod spec at creation time without any security validation. The podSpecPatch is a JSON string validated only syntactically against the Kubernetes PodSpec schema but not checked for dangerous security settings."}, {'type': 'paragraph', 'content': 'This allows attackers to override security contexts, enabling privileged containers, running as root, mounting host filesystems, sharing host namespaces, and adding all Linux capabilities, effectively bypassing all admin-imposed security constraints.'}] [1]

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including privilege escalation to root on the Kubernetes node, bypassing all security restrictions set by administrators.

• Attackers can run containers with privileged access and root user privileges.
• They can mount host filesystems via hostPath volumes, potentially accessing sensitive data.
• They can share host PID, network, and IPC namespaces, increasing the attack surface.
• They can add all Linux capabilities to containers, further escalating control.

Overall, exploitation can compromise the confidentiality, integrity, and availability of the system and potentially other connected systems.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring submitted Workflows for the presence of the `podSpecPatch` field, especially when the controller is configured with `templateReferencing: Strict` mode.'}, {'type': 'paragraph', 'content': 'Since the `podSpecPatch` field allows overriding security settings without validation, detection involves inspecting Workflow submissions for this field and checking for dangerous pod settings such as `privileged: true`, `hostPID`, `hostNetwork`, `hostIPC`, `hostPath` volumes, or running as root (`runAsUser: 0`).'}, {'type': 'paragraph', 'content': 'Administrators can use Kubernetes commands to list Workflows and inspect their specifications. For example, using `kubectl` commands to get Workflow YAML and grep for `podSpecPatch` or suspicious security context settings.'}, {'type': 'list_item', 'content': 'kubectl get workflows -A -o yaml | grep -A 10 podSpecPatch'}, {'type': 'list_item', 'content': 'kubectl get workflows -A -o jsonpath=\'{range .items[*]}{.metadata.name}{": "}{.spec.podSpecPatch}{"\\n"}{end}\''}, {'type': 'list_item', 'content': "kubectl get workflows -A -o yaml | grep -E 'privileged|hostPID|hostNetwork|hostIPC|hostPath|runAsUser'"}, {'type': 'paragraph', 'content': 'Additionally, deploying admission controllers like OPA/Gatekeeper or Kyverno can help detect and block dangerous pod settings in real time.'}] [1]

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include configuring the Argo Workflows controller to reject any Workflow submissions that include the `podSpecPatch` field when `templateReferencing: Strict` or `Secure` mode is enabled.

Until the fixed versions (3.7.11 and 4.0.2) are deployed, administrators should deploy admission controllers such as OPA/Gatekeeper or Kyverno to block dangerous pod settings that can be exploited via `podSpecPatch`.

• Block pod specifications that enable `privileged` containers.
• Block pods that use `hostPID`, `hostNetwork`, or `hostIPC` namespaces.
• Block pods mounting host filesystems via `hostPath` volumes.

Upgrading Argo Workflows to versions 3.7.11 or 4.0.2, where this vulnerability is fixed, is the definitive solution.

Useful 0 Not Useful 0