CVE-2026-42296

The fix for CVE-2026-31892 (commit 534f4ff) blocks podSpecPatch when templateReferencing: Strict is active, but doesn't restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set hostNetwork: true, override serviceAccountName, or change securityContext on their Workflow while referencing a hardened template -- these survive JoinWorkflowSpec and get applied at pod creation.

The check in setExecWorkflow gates on HasPodSpecPatch() only:

if woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {

Everything else passes through. createWorkflowPod reads hostNetwork, securityContext, serviceAccountName, tolerations, and automountServiceAccountToken from the merged spec and applies them directly to the pod.

JoinWorkflowSpec constructs the merge target from the user's spec and applies the template as a patch -- user fields take priority. When the template doesn't explicitly set a field like hostNetwork (most won't -- false is the zero value and gets omitted), the user's true survives. For fields like securityContext and serviceAccountName, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.

Both Strict and Secure modes are affected. Secure stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent MustNotChangeSpec comparisons pass.

Steps to reproduce

Tested on v4.0.2 (the CVE-2026-31892 patched version) on kind v0.27.0 / K8s v1.35.0.

# enable strict mode
kubectl patch configmap workflow-controller-configmap -n argo --type merge \
  -p '{"data":{"workflowRestrictions":"templateReferencing: Strict\n"}}'
kubectl rollout restart deployment workflow-controller -n argo

A template that lists network interfaces:

cat <<'EOF' | kubectl apply -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: netcheck
spec:
  entrypoint: check
  templates:
  - name: check
    container:
      image: alpine:latest
      command: ["/bin/sh", "-c"]
      args: ["ip addr show | grep -E '^[0-9]+:' | cut -d: -f2"]
EOF

Submit a workflow with hostNetwork: true:

cat <<'EOF' | kubectl create -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: bypass-
spec:
  workflowTemplateRef:
    name: netcheck
  hostNetwork: true
EOF

Pod gets host networking:

$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-bmg9b -o jsonpath='{.items[0].spec.hostNetwork}'
true

Container without the override sees eth0@if20. With the override, the pod sees the host's full network namespace -- all veth interfaces for other containers on the node.

podSpecPatch IS correctly blocked on the same cluster:

$ kubectl get workflow patched-check-jd272 -n argo -o jsonpath='{.status.message}'
podSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction

serviceAccountName override also works -- a workflow with serviceAccountName: argo-server creates a pod running under the argo-server SA instead of the namespace default:

$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-sa-slmjs -o jsonpath='{.items[0].spec.serviceAccountName}'
argo-server

Tested in Secure mode as well -- same result. Pod created with hostNetwork: true before the workflow errors on an unrelated permission issue.

Fix direction

The check in setExecWorkflow should cover all WorkflowSpec fields that influence pod security posture, not just podSpecPatch. The affected fields that I confirmed in createWorkflowPod: hostNetwork, securityContext, serviceAccountName, automountServiceAccountToken, tolerations, dnsPolicy, schedulerName, hostAliases, volumes.

An alternative approach: when MustUseReference() is true, strip all user-set WorkflowSpec fields except a known-safe allowlist (entrypoint, arguments, labels, annotations) before merging. This avoids a growing denylist as new fields get added.

Affected versions

All versions supporting templateReferencing, including v4.0.2 and v3.7.11 which patched CVE-2026-31892.

A user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature.

The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo's Strict mode as the primary enforcement layer are fully exposed.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-42296 has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.7.14, 4.0.5); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-42296? CVE-2026-42296 is a high-severity incorrect authorization vulnerability in github.com/argoproj/argo-workflows/v3 (go), affecting versions < 3.7.14. It is fixed in 3.7.14, 4.0.5. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-42296? CVE-2026-42296 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which packages are affected by CVE-2026-42296?
   • github.com/argoproj/argo-workflows/v3 (go) (versions < 3.7.14)
   • github.com/argoproj/argo-workflows/v4 (go) (versions >= 4.0.0, < 4.0.5)
4. Is there a fix for CVE-2026-42296? Yes. CVE-2026-42296 is fixed in 3.7.14, 4.0.5. Upgrade to this version or later.
5. Is CVE-2026-42296 exploitable, and should I be worried? Whether CVE-2026-42296 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-42296 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-42296?
   • Upgrade github.com/argoproj/argo-workflows/v3 to 3.7.14 or later
   • Upgrade github.com/argoproj/argo-workflows/v4 to 4.0.5 or later