CVE-2026-31892
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk33th percentile - higher than 33% of all known CVEs
Summary
A vulnerability in Argo Workflows allows a user with Workflow submission privileges to completely bypass all security settings defined in a WorkflowTemplate. By including a podSpecPatch field in their submitted Workflow, the user can override template settings even when the controller is configured with templateReferencing: Strict.
Risk Assessment
The organization faces the risk of privilege escalation and execution of unauthorized containers with arbitrary parameters, potentially leading to Kubernetes resource isolation breaches and cluster takeover.
Recommendation
Immediately upgrade Argo Workflows to version 4.0.2 or 3.7.11, which contain the fix for this vulnerability. Until the update is applied, restrict Workflow submission access to trusted users only.
Other vulnerabilities in Argo Workflows
See all- CVE-2026-54526Critical
A vulnerability in Argo Workflows before versions 3.7.15 and 4.0.6 allows bypassing the allow-list fix for CVE-2026-31892. Through the ArtifactGC field in WorkflowSpec, a user can inject an arbitrary strategic merge patch into the artifact-GC pod, including dangerous settings like hostPath, privileged mode, or hostNetwork.
- CVE-2026-28229Critical
Argo Workflows prior to versions 4.0.2 and 3.7.11 contains a vulnerability that allows unauthorized clients to retrieve WorkflowTemplates and ClusterWorkflowTemplates by sending a request with any token in the Authorization header. This can lead to disclosure of sensitive data, including embedded Secret manifests.
- CVE-2026-42297High
Argo Workflows versions 4.0.0 to before 4.0.5 have a vulnerability in the Sync Service where the ConfigMap-backed provider performs zero authorization checks on CRUD operations. Any authenticated user, including those using fake Bearer tokens, can create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits.
- CVE-2026-42296High
Argo Workflows before versions 3.7.14 and 4.0.5 allows a user with create Workflow permission to bypass Strict templateReferencing mode. This enables host network access, service account switching, pod security context override, tolerations for control-plane nodes, or SA token mounting.
- CVE-2026-42295Medium
Argo Workflows from version 4.0.0 to before 4.0.5 logs all artifact repository credentials (S3 access keys, secret keys, GCS service account keys, Azure account keys, Git passwords, etc.) in plaintext during artifact operations. Any user with read access to workflow pod logs can extract these credentials. This is fixed in version 4.0.5.
- CVE-2026-42294High
Argo Workflows before versions 3.7.14 and 4.0.5 loads the entire request body into memory before authentication or signature verification on the publicly accessible /api/v1/events/ endpoint. An attacker can send a very large request, causing excessive memory usage and an OOM crash.
- CVE-2026-42183Medium
Argo Workflows versions 4.0.0 to 4.0.5 have a nil pointer dereference in rbacAuthorization() in server/auth/gatekeeper.go, causing a panic (denial of service) for SSO users whose claims match a namespace-level RBAC rule but not an SSO-namespace rule when SSO_DELEGATE_RBAC_TO_NAMESPACE=true.
- CVE-2026-40886High
A vulnerability in Argo Workflows from version 3.6.5 to 4.0.4 causes a controller panic due to an unchecked array index in the pod informer's podGCFromPod() function. A malicious workflows.argoproj.io/pod-gc-strategy annotation on a workflow pod crashes the entire controller process, and after restart, it creates a crash loop that halts all workflow processing.
- CVE-2026-23960Medium
Stored XSS vulnerability in Argo Workflows allows arbitrary JavaScript execution in another user's browser via artifact directory listing. Affects versions prior to 3.6.17 and 3.7.8.
Original NVD description (English source)
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.