CVE-2026-42296: Argo Workflows Auth Bypass Vulnerability

CVE-2026-42296 Overview

CVE-2026-42296 is an authorization bypass vulnerability [CWE-863] in Argo Workflows, an open-source container-native workflow engine for Kubernetes. The flaw affects versions prior to 3.7.14 and 4.0.5. A user with create Workflow permission can bypass the templateReferencing: Strict enforcement by supplying a podSpecPatch in a workflow that references a WorkflowTemplate. This bypass allows attackers to gain host network access, switch service accounts, override pod security contexts, add tolerations to schedule pods on control-plane nodes, or enable service account token mounting.

Critical Impact

Authenticated workflow creators can defeat Argo's primary template restriction control, escalating privileges within the Kubernetes cluster when no compensating admission controls exist.

Affected Products

• Argoproj Argo Workflows versions prior to 3.7.14 (3.x branch)
• Argoproj Argo Workflows versions prior to 4.0.5 (4.x branch)
• Kubernetes clusters relying on Argo templateReferencing: Strict as the primary enforcement layer

Discovery Timeline

• 2026-05-09 - CVE-2026-42296 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-42296

Vulnerability Analysis

Argo Workflows provides a templateReferencing: Strict mode in WorkflowRestrictions. This mode is intended to force workflows to use only approved WorkflowTemplate resources, preventing inline specification of arbitrary pod settings. The vulnerability stems from incomplete enforcement: the controller honored the template reference but still applied any podSpecPatch supplied alongside it. A podSpecPatch is a JSON or YAML patch that mutates the final pod spec produced by the workflow. An attacker with permission to create a Workflow object can submit a workflow referencing an approved template while injecting a podSpecPatch that overrides the security-relevant fields the template was designed to lock down. The CWE-863 classification reflects the incorrect authorization decision the controller made when reconciling the patch against the strict policy.

Root Cause

The controller did not reject workflows that combined WorkflowTemplateRef with podSpecPatch when restrictions required template referencing. The patch must be evaluated against the policy before merging, but the pre-patch logic in setExecWorkflow skipped this check.

Attack Vector

The attacker requires only standard create permission on Workflow resources in a target namespace. They submit a workflow that references a vetted WorkflowTemplate and includes a podSpecPatch setting hostNetwork: true, replacing serviceAccountName, adding control-plane tolerations, or removing automountServiceAccountToken: false. The controller renders the patched pod spec and schedules it.

func (woc *wfOperationCtx) setExecWorkflow(ctx context.Context) (context.Context, error) {
	switch {
	case woc.wf.Spec.WorkflowTemplateRef != nil: // not-woc-misuse
		// When workflow restrictions require template referencing (Strict/Secure mode),
		// reject workflows that include a podSpecPatch as it could override security
		// settings defined in the WorkflowTemplate.
		if woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {
			err := fmt.Errorf("podSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction")
			ctx = woc.markWorkflowError(ctx, err)
			return ctx, err
		}
		err := woc.setStoredWfSpec(ctx)
		if err != nil {
			ctx = woc.markWorkflowError(ctx, err)

Source: Argo Workflows patch commit 534f4ff. The fix adds a guard that rejects any submitted workflow combining WorkflowTemplateRef with podSpecPatch while the controller is configured with MustUseReference().

Detection Methods for CVE-2026-42296

Indicators of Compromise

• Argo Workflow objects that reference a WorkflowTemplate and also contain a spec.podSpecPatch field.
• Pods created by Argo executors running with hostNetwork: true, mounted service account tokens, or scheduled on control-plane nodes via node-role.kubernetes.io/control-plane tolerations.
• Service account changes inside Argo-managed pods that do not match the referenced WorkflowTemplate.

Detection Strategies

• Audit Kubernetes API server logs for create and update calls on workflows.argoproj.io containing a podSpecPatch key in the request body.
• Compare runtime pod specs against the referenced WorkflowTemplate to flag any divergence in securityContext, serviceAccountName, tolerations, or hostNetwork.
• Enable PodSecurity admission in restricted profile and OPA/Gatekeeper or Kyverno policies that independently reject privileged pod fields.

Monitoring Recommendations

• Alert on Argo controller log entries referencing podSpecPatch rejection messages after upgrading, which indicate active exploit attempts.
• Monitor for pods labeled with workflows.argoproj.io/workflow running on control-plane nodes or with non-default service accounts.
• Track outbound network connections from workflow pods that should be sandboxed by hostNetwork: false.

How to Mitigate CVE-2026-42296

Immediate Actions Required

• Upgrade Argo Workflows to version 3.7.14 or 4.0.5 in every cluster running the controller.
• Inventory existing Workflow and CronWorkflow resources for unexpected podSpecPatch usage combined with workflowTemplateRef.
• Restrict RBAC create and update permissions on workflows.argoproj.io to trusted service accounts and users.

Patch Information

The upstream fix is published in GitHub Release v3.7.14 and GitHub Release v4.0.5. Technical details are documented in GHSA-3775-99mw-8rp4. The corresponding source change is in commit 534f4ff1.

Workarounds

• Enable Kubernetes PodSecurity admission with the restricted profile on namespaces hosting Argo workflows to independently block hostNetwork, privileged service account use, and control-plane tolerations.
• Deploy OPA/Gatekeeper or Kyverno policies that deny any pod spec containing hostNetwork: true, control-plane tolerations, or service account overrides not matching the parent WorkflowTemplate.
• Use a validating admission webhook to reject any Workflow containing both workflowTemplateRef and podSpecPatch until the controller upgrade is complete.

# Kyverno ClusterPolicy enforcing the workaround pre-upgrade
kubectl apply -f - <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-argo-podspecpatch-with-templateref
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-podspecpatch
      match:
        any:
          - resources:
              kinds:
                - argoproj.io/v1alpha1/Workflow
      validate:
        message: "podSpecPatch is not permitted alongside workflowTemplateRef"
        deny:
          conditions:
            all:
              - key: "{{ request.object.spec.workflowTemplateRef || '' }}"
                operator: NotEquals
                value: ""
              - key: "{{ request.object.spec.podSpecPatch || '' }}"
                operator: NotEquals
                value: ""
EOF