CVE-2026-42296
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk35th percentile - higher than 35% of all known CVEs
Summary
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.
Risk Assessment
The risk depends on additional Kubernetes controls. If the organization relies solely on Argo's Strict mode as the primary enforcement layer, it is fully exposed to unauthorized access and privilege escalation.
Recommendation
Immediately upgrade Argo Workflows to version 3.7.14 or 4.0.5. Additionally, implement independent controls such as PodSecurity admission or OPA/Gatekeeper.
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-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-31892High
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.
- 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. Prior to versions 3.7.14 and 4.0.5, 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. This issue has been patched in versions 3.7.14 and 4.0.5.