Argo Workflows
CVE-2026-31892
HIGH
GHSA-3wf5-g532-rcrr
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Authenticated submit user (PR:L) over the network (AV:N) bypasses validation to create privileged pods, breaching the controller/template trust boundary (S:C) with high confidentiality and integrity impact.
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
10DescriptionCVE.org
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. From 2.9.0 to before 4.0.2 and 3.7.11, A user who can submit Workflows can completely bypass all security settings defined in a WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This works even when the controller is configured with templateReferencing: Strict, which is specifically documented as a mechanism to restrict users to admin-approved templates. The podSpecPatch field on a submitted Workflow takes precedence over the referenced WorkflowTemplate during spec merging and is applied directly to the pod spec at creation time with no security validation. This vulnerability is fixed in 4.0.2 and 3.7.11.
AnalysisAI
Authorization bypass in Argo Workflows (2.9.0 through 4.0.1 and 3.7.x before 3.7.11) lets any user permitted to submit Workflows override admin-defined WorkflowTemplate security controls by attaching a podSpecPatch to their submission. Because podSpecPatch is merged with Workflow-spec precedence and applied to the pod with no security validation, even controllers locked down with templateReferencing: Strict can be circumvented to run arbitrary pod settings such as privileged: true. Publicly available exploit code exists, but EPSS is low (0.04%) and it is not in CISA KEV.
Technical ContextAI
Argo Workflows is a container-native workflow engine that schedules parallel jobs as Kubernetes pods. Administrators use WorkflowTemplates plus the controller's workflowRestrictions (templateReferencing: Strict/Secure) to constrain users to pre-approved, hardened pod definitions. The CWE-863 (Improper Authorization) root cause is a merge-and-validate gap: JoinWorkflowSpec merges with priority Workflow Spec > WorkflowTemplate Spec > WorkflowDefault Spec, so a string field like podSpecPatch supplied on the Workflow wholesale replaces the template's value; ApplyPodSpecPatch only validates that the patch is syntactically valid JSON conforming to the Kubernetes PodSpec schema and performs no security checks (e.g., privileged, hostPath, securityContext); and Strict mode only verifies that WorkflowTemplateRef is set, ignoring any other co-submitted fields. The affected component is the Go module github.com/argoproj/argo-workflows (CPE cpe:2.3:a:argoproj:argo_workflows), spanning the v3 and v4 module paths.
RemediationAI
Primary fix: upgrade Argo Workflows to a patched release - Vendor-released patch: 4.0.2 (for the v4 line) or 3.7.11 (for the 3.7.x line), per advisory GHSA-3wf5-g532-rcrr (https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3wf5-g532-rcrr); if running a vendor-packaged build, apply the corresponding Red Hat (RHSA-2026:10184) or SUSE (SUSE-SU-2026:1042) errata. Until patched, do not treat templateReferencing: Strict as a sufficient security boundary. Practical compensating controls: tighten RBAC so that only trusted principals hold workflow create/submit permissions (reduces the population that can abuse the bypass, at the cost of self-service workflow submission); deploy an admission controller such as OPA Gatekeeper or Kyverno to reject submitted Workflows that carry a podSpecPatch field or that set dangerous pod settings like privileged: true, hostPath mounts, or hostPID/hostNetwork (effective but requires policy authoring and may break legitimate workflows that rely on podSpecPatch); and enforce restrictive Pod Security Admission (restricted profile) and seccomp/no-privileged policies at the namespace level so that even a smuggled patch cannot create a privileged pod (strong defense, but may block workloads that genuinely need elevated capabilities). Patching remains the only complete remedy.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: HighShare
External POC / Exploit Code
Leaving vuln.today