Introduction
A single malformed annotation on a Kubernetes workflow pod can crash the entire Argo Workflows controller and keep it down indefinitely through a persistent crash loop. CVE-2026-40886, scored at CVSS 7.7, exposes a denial of service condition where any user with baseline workflow creation permissions can halt all workflow processing across a cluster until an administrator manually intervenes.
Argo Workflows is an open source, container native workflow engine for orchestrating parallel jobs on Kubernetes. It is widely adopted for CI/CD pipelines, machine learning model training, and data processing tasks, making it a critical piece of infrastructure in many Kubernetes environments. A controller level denial of service in this component has broad implications for organizations relying on it for production workloads.
Technical Information
Root Cause: Unchecked Array Index in podGCFromPod()
The vulnerability lives in the podGCFromPod() function within the pod informer. This function is responsible for parsing the workflows.argoproj.io/pod-gc-strategy annotation from workflow pods. The implementation splits the annotation value on the / character and unconditionally accesses the second element of the resulting array:
func podGCFromPod ( pod * apiv1. Pod ) wfv1. PodGC { if val, ok := pod. Annotations [ common. AnnotationKeyPodGCStrategy ]; ok { parts := strings. Split ( val, "/" ) return wfv1. PodGC { Strategy : wfv1. PodGCStrategy ( parts [ 0 ]), DeleteDelayDuration : parts [ 1 ]} } return wfv1. PodGC { Strategy : wfv1. PodGCOnPodNone } }
When the annotation value does not contain a / character (for example, a value like "NoSlash"), strings.Split returns a slice with a single element. The unconditional access to parts[1] then triggers a Go runtime panic: index out of range [1] with length 1.
This is a textbook CWE-129 (Improper Validation of Array Index) issue. The code assumes the annotation will always contain a delimiter without performing any bounds check.
Why the Panic is Fatal to the Controller
The critical detail that elevates this from a recoverable error to a full denial of service is where the panic occurs. The podGCFromPod() function runs inside a Kubernetes informer goroutine. Informer goroutines operate outside the controller's recover() scope, meaning the panic propagates uncaught and terminates the entire controller process.
Persistent Crash Loop Mechanism
The denial of service is not a one time crash. The poisoned pod (the workflow pod carrying the malformed annotation) persists in the Kubernetes cluster. When the controller restarts (as Kubernetes will automatically attempt), the informer immediately processes the existing pods, encounters the poisoned annotation again, and panics. This creates a CrashLoopBackOff cycle that continues indefinitely.
No workflows in the cluster can make progress while the controller is in this state. The only way to break the loop is to manually delete the offending workflow pod before the controller restarts and processes it.
Attack Flow
- An attacker with
createpermission on Workflow resources (the baseline permission for any Argo Workflows user) submits a workflow manifest containing a pod with the annotationworkflows.argoproj.io/pod-gc-strategy: "NoSlash". - The workflow pod is created in the cluster with the malformed annotation.
- The pod informer in the Argo Workflows controller processes the new pod and calls
podGCFromPod(). - The function splits
"NoSlash"on/, producing a single element slice, then attempts to accessparts[1]. - The Go runtime panics with
index out of range [1] with length 1. - Because the panic is in an informer goroutine outside
recover()scope, the entire controller process crashes. - Kubernetes restarts the controller pod, the informer re-processes the poisoned pod, and the cycle repeats.
Observable Artifacts
Administrators can confirm this specific vulnerability by checking controller logs for the following panic signature:
panic: runtime error: index out of range [1] with length 1 goroutine 291 [running]: github.com/argoproj/argo-workflows/v4/workflow/controller/pod.podGCFromPod(...) /home/runner/work/argo-workflows/argo-workflows/workflow/controller/pod/controller.go:176
The controller pod will show CrashLoopBackOff status with an increasing restart count.
Affected Systems and Versions
The vulnerability affects multiple release branches of Argo Workflows:
| Release Branch | Affected Versions | Patched Version |
|---|---|---|
| 4.x | 4.0.0 through 4.0.4 | 4.0.5 |
| 3.7.x | 3.7.0 through 3.7.13 | 3.7.14 |
| 3.6.x | 3.6.5 through 3.6.19 | No patch listed; upgrade to 3.7.14 or 4.0.5 |
Versions 3.6.4 and earlier are not affected by this vulnerability. The patched versions 4.0.5 and 3.7.14 were released on April 23, 2026.
Organizations running the 3.6.x branch on versions 3.6.5 or later should upgrade to 3.7.14 or 4.0.5, as no patch has been listed for the 3.6.x line.
Vendor Security History
The Argo Workflows project has maintained a responsive patching cadence, but 2026 has surfaced multiple high severity vulnerabilities related to input validation and security bypasses:
| CVE ID | Vulnerability Type | Severity | Fixed Versions | Publish Date |
|---|---|---|---|---|
| CVE-2026-40886 | CWE-129: Improper Validation of Array Index | CVSS 7.7 (High) | 4.0.5, 3.7.14 | April 23, 2026 |
| CVE-2026-31892 | CWE-863: Incorrect Authorization (WorkflowTemplate Bypass) | CVSS 8.9 (High) | 4.0.2, 3.7.11 | March 11, 2026 |
CVE-2026-31892 allowed users to bypass security settings via the podSpecPatch field, representing a similar pattern of vulnerabilities stemming from insufficient validation of user supplied spec data. The vendor's turnaround on fixes has been strong in both cases, with patches for CVE-2026-40886 published the same day as the advisory.
