CVE-2026-40886
HighCVSS 7.7Exploitation Probability (EPSS)
Low risk30th percentile - higher than 30% of all known CVEs
Summary
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.
Risk Assessment
The risk is a complete halt of workflow processing in the Kubernetes cluster, potentially causing disruptions to applications and services relying on Argo Workflows. An attacker can intentionally place a malformed pod, causing continuous controller crashes.
Recommendation
Immediately upgrade Argo Workflows to version 4.0.5 or 3.7.14, which contain the fix. In the meantime, if possible, manually remove any pods with the workflows.argoproj.io/pod-gc-strategy annotation.
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-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. From 3.6.5 to 4.0.4, an unchecked array index in the pod informer's podGCFromPod() function causes a controller-wide panic when a workflow pod carries a malformed workflows.argoproj.io/pod-gc-strategy annotation. Because the panic occurs inside an informer goroutine (outside the controller's recover() scope), it crashes the entire controller process. The poisoned pod persists across restarts, causing a crash loop that halts all workflow processing until the pod is manually deleted. This vulnerability is fixed in 4.0.5 and 3.7.14.