JustAppSec
Back to news

Argo Workflows template restriction bypass exposes pod security controls

2 min readPublished 09 May 2026Source: CVEProject (cvelistV5)
CVE-2026-42296CVE-2026-31892NewsKubernetesCI/CD SecurityAuthorization

TL;DR - Argo Workflows blocks podSpecPatch under templateReferencing: Strict/Secure, but other pod-affecting fields still flow through the merge path. Anyone with create Workflow permission can set hostNetwork: true, swap serviceAccountName, override securityContext, add tolerations, or enable automountServiceAccountToken. This is an incomplete fix for CVE-2026-31892.

What happened

Argo Workflows is a Kubernetes-native workflow engine. It compiles workflow specs into pods via a controller and a set of CRDs. The templateReferencing: Strict and Secure modes exist to force users to run centrally managed, hardened WorkflowTemplates - the idea being that administrators define the template, and submitters cannot alter pod security posture.

CVE-2026-42296 (published 9 May 2026) documents exactly where that assumption breaks. Argo blocks podSpecPatch, but the merge path that assembles the final pod spec still accepts other WorkflowSpec fields that carry security weight. Those fields are applied at pod creation without restriction.

Fields confirmed exploitable via this bypass:

  • hostNetwork: true
  • serviceAccountName substitution
  • securityContext overrides
  • tolerations (scheduling influence)
  • automountServiceAccountToken

This is an incomplete-fix class issue. The advisory frames it explicitly as such - a continuation of CVE-2026-31892, not a standalone finding. If you are relying on templateReferencing as a policy boundary in a multi-tenant cluster, this is a real privilege boundary failure. Not a minor configuration gap. For broader context on authorization failures in this class, see our authorization bypass research and the Kubernetes security hardening guide.

Who is impacted

  • Clusters where untrusted tenants can submit Argo workflows, or where teams treat templateReferencing: Strict / Secure as the primary guardrail for pod security posture.
  • Any environment where Argo restriction modes are the enforcement layer - rather than a defence-in-depth layer - for pod-level controls.
Affected lineAffected versionsPatched version
3.x< 3.7.143.7.14
4.x>= 4.0.0, < 4.0.54.0.5

The advisory notes that impact depends on your broader Kubernetes controls. Clusters enforcing PodSecurity admission or running OPA/Gatekeeper may independently block some of the bypassed fields - hostNetwork in particular. That is mitigation, not a fix.

What to do now

  • Patch first. Apply 3.7.14 or 4.0.5 depending on your release line.
  • If you depend on templateReferencing: Strict or Secure as a security control:
    • Audit who holds create Workflow permission in namespaces managed by Argo.
    • Review recent workflow submissions for pod-affecting fields: hostNetwork, serviceAccountName, securityContext, tolerations, automountServiceAccountToken.
  • Enforce Kubernetes-native controls that are independent of Argo's merge semantics. PodSecurity admission and OPA/Gatekeeper both provide enforcement that does not rely on Argo getting the merge right.
  • If you suspect exploitation, scope for unexpected service account usage across pods created by Argo. Rotate credentials reachable from those pods.

Additional information

Need help?Get in touch.