CVE-2026-31892
Privilege Escalation via podSpecPatch in Argo Workflows
Publication date: 2026-03-11
Last updated on: 2026-03-17
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| argoproj | argo_workflows | From 2.9.0 (inc) to 3.7.11 (exc) |
| argoproj | argo_workflows | From 4.0.0 (inc) to 4.0.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'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]
How can this vulnerability impact me? :
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.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'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]
What immediate steps should I take to mitigate this vulnerability?
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.