CVE-2026-31892
Received Received - Intake
Privilege Escalation via podSpecPatch in Argo Workflows

Publication date: 2026-03-11

Last updated on: 2026-03-17

Assigner: GitHub, Inc.

Description
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. From 2.9.0 to before 4.0.2 and 3.7.11, A user who can submit Workflows can completely bypass all security settings defined in a WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This works even when the controller is configured with templateReferencing: Strict, which is specifically documented as a mechanism to restrict users to admin-approved templates. The podSpecPatch field on a submitted Workflow takes precedence over the referenced WorkflowTemplate during spec merging and is applied directly to the pod spec at creation time with no security validation. This vulnerability is fixed in 4.0.2 and 3.7.11.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-11
Last Modified
2026-03-17
Generated
2026-06-16
AI Q&A
2026-03-11
EPSS Evaluated
2026-06-14
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
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
CWE Icon
KEV
KEV Icon
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 Quick Actions
Instant insights powered by AI
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]

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.

Compliance Impact

I don't know

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]

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.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-31892. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart