CVE-2026-31892: Argo Workflows WorkflowTemplate Security Bypass via podSpecPatch

Argo Workflows relies on a Custom Resource Definition (CRD) called WorkflowTemplate to define secure, pre-approved execution environments for cluster users. Administrators configure the workflow controller with a setting named templateReferencing: Strict (or Secure) to enforce compliance with these templates. This configuration ensures that users cannot execute arbitrary workflows but must instead instantiate templates pre-authorized by cluster administrators.

CVE-2026-31892 represents an incorrect authorization vulnerability (CWE-863) within the workflow submission logic. The vulnerability manifests when the controller processes a user submission that references a valid template but concurrently includes overriding configuration directives. The controller fails to isolate the user-provided execution parameters from the administratively defined template parameters.

Specifically, the podSpecPatch field allows users to submit raw Kubernetes strategic merge patches or JSON patches that modify the resulting Pod specification. The controller accepts this field even when operating in Strict template referencing mode. Consequently, an attacker can append high-privilege configuration directives to an otherwise restricted execution template.

The fundamental flaw exists within the specification merging process executed by the Argo Workflows controller. When a user submits a workflow referencing a WorkflowTemplate, the controller invokes the JoinWorkflowSpec function to reconcile the user-provided specification with the template specification. This function employs a "last-one-wins" merge hierarchy, granting the user's submission precedence over the template's defaults.

In Strict mode, the controller's validation logic historically performed a superficial verification. It confirmed the presence of a valid workflowTemplateRef in the submission but failed to validate or prohibit additional fields that alter the pod execution environment. The podSpecPatch field bypasses the template restrictions because the controller does not explicitly reject it during the validation phase.

Furthermore, the ApplyPodSpecPatch() function applies the user-provided patch directly to the pod specification at creation time. This function performs basic syntactic validation to ensure the patch conforms to the PodSpec schema and is valid YAML or JSON. However, it entirely lacks semantic security checks. The controller does not restrict security-sensitive fields such as securityContext.privileged, hostPID, or hostPath mounts when applying the patch.

The remediation involves modifications to the workflow validation logic within the controller. The patch ensures that if template restrictions are enabled, the controller strictly rejects any workflow submission containing a podSpecPatch. The fix was applied across both the 3.7.x and 4.0.x release branches.

Prior to the patch, the validator permitted the workflow to proceed as long as the workflowTemplateRef pointed to a valid resource. The patched implementation introduces a specific check during workflow evaluation. The controller evaluates the configuration state of WorkflowRestrictions.MustUseReference() and subsequently checks the submitted workflow for the presence of the patch field.

// Added validation logic in the workflow controller
if woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {
    err := fmt.Errorf("podSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction")
    woc.markWorkflowError(ctx, err)
    return err
}

The HasPodSpecPatch() method inspects the submission for any provided patches. If the boolean condition evaluates to true under strict template referencing, the controller immediately halts execution, marks the workflow with an error state via markWorkflowError(), and returns the error without creating the associated Pod resources.

Exploitation requires an authenticated attacker possessing Kubernetes Role-Based Access Control (RBAC) permissions to create Workflows within a target namespace. The attacker must first identify an existing, valid WorkflowTemplate that the controller permits under the Strict configuration. The content or intended function of this template is irrelevant to the attack success.

The attacker crafts a malicious workflow submission that references the identified template via workflowTemplateRef. The attacker simultaneously injects the podSpecPatch field into the specification. The payload within the patch targets the pod's security context and volume configurations to request elevated privileges.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: exploit-
spec:
  workflowTemplateRef:
    name: secure-admin-template
  podSpecPatch: |
    containers:
      - name: main
        securityContext:
          privileged: true
          runAsUser: 0
    hostPID: true
    volumes:
      - name: host-root
        hostPath:
          path: /

Upon submission, the Argo Workflows controller merges the payload, applies the patch, and requests Pod creation from the Kubernetes API. The resulting Pod executes with root privileges (runAsUser: 0), shares the host's process namespace (hostPID: true), and mounts the entire host filesystem (hostPath: /). The attacker can then execute arbitrary commands against the underlying Kubernetes node.

The vulnerability carries a CVSS 4.0 score of 8.9 (High). Successful exploitation yields complete container escape and host-level privilege escalation. By mounting the host root filesystem into the container, the attacker gains full read and write access to the node's operating system environment.

The attacker can access sensitive node-level components, including the kubelet configuration, locally stored secrets, and container runtime sockets. Reading the kubelet credentials typically allows the attacker to pivot from node-level access to cluster-wide compromise, depending on the specific RBAC permissions granted to the node's service account.

The attack vector is restricted by the requirement for initial authentication and specific RBAC permissions (create workflow). The vulnerability does not allow unauthenticated external actors to compromise the cluster directly. However, it completely invalidates the administrative boundaries established by Argo Workflows' template mechanisms.

The primary mitigation requires upgrading the Argo Workflows controller to the officially patched versions. Organizations must deploy version 4.0.2 or 3.7.11 to resolve the logic flaw in the workflow validation sequence. Upgrading the controller binary ensures that the HasPodSpecPatch() check is enforced correctly during template referencing.

Administrators must verify that templateReferencing: Strict or Secure remains enabled within the controller configuration. The vulnerability primarily affects environments relying on this setting to enforce execution boundaries. Without this setting enabled, users already possess the ability to define arbitrary pod specifications by design.

As a defense-in-depth measure, administrators should deploy Kubernetes Admission Controllers such as OPA Gatekeeper or Kyverno. These tools evaluate Pod creation requests at the Kubernetes API server level, operating independently of Argo Workflows. Configuring policies to block Pods requesting privileged: true, hostPID, or sensitive hostPath mounts prevents privilege escalation regardless of vulnerabilities in higher-level operators.