Argo Workflows CVE-2026-40886: Brief Summary of a Controller Crash Loop via Malformed Annotation Parsing

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 (CVSS 7.7) is a denial-of-service condition in which any user with baseline workflow creation permissions can halt all workflow processing across a cluster until an administrator steps in manually.

Argo Workflows is an open-source, container-native workflow engine for orchestrating parallel jobs on Kubernetes. Teams use it widely for CI/CD pipelines, machine learning model training, and data processing, so in many Kubernetes environments it is core infrastructure. A controller-level denial of service in this component affects any organization that relies on it for production workloads.

Technical information

Root cause: unchecked array index in podGCFromPod()

The vulnerability lives in the podGCFromPod() function in the pod informer. This function parses the workflows.argoproj.io/pod-gc-strategy annotation from workflow pods. It splits the annotation value on the / character and then reads the second element of the resulting array without checking that it exists:

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 has no / 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 and never checks bounds.

Why the panic is fatal to the controller

What turns this from a recoverable error into a full denial of service is where the panic happens. podGCFromPod() runs inside a Kubernetes informer goroutine. Informer goroutines operate outside the controller's recover() scope, so the panic propagates uncaught and terminates the entire controller process.

Persistent crash loop mechanism

The crash also repeats. The poisoned pod (the workflow pod carrying the malformed annotation) stays in the Kubernetes cluster. Kubernetes automatically tries to restart the controller, and on each restart the informer immediately processes the existing pods, hits the poisoned annotation again, and panics. The result is 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

1. An attacker with create permission on Workflow resources (the baseline permission for any Argo Workflows user) submits a workflow manifest containing a pod with the annotation workflows.argoproj.io/pod-gc-strategy: "NoSlash".
2. The cluster creates the workflow pod with the malformed annotation.
3. The pod informer in the Argo Workflows controller processes the new pod and calls podGCFromPod().
4. The function splits "NoSlash" on /, producing a single-element slice, then attempts to access parts[1].
5. The Go runtime panics with index out of range [1] with length 1.
6. Because the panic is in an informer goroutine outside recover() scope, the entire controller process crashes.
7. Kubernetes restarts the controller pod, the informer re-processes the poisoned pod, and the cycle repeats.

Observable artifacts

Administrators can confirm this 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 three release branches of Argo Workflows:

Versions 3.6.4 and earlier are not affected. 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, because no patch has been listed for the 3.6.x line.

Vendor security history

The Argo Workflows project patches quickly, but 2026 has surfaced multiple high-severity vulnerabilities involving input validation and security bypasses:

CVE-2026-31892 let users bypass security settings through the podSpecPatch field. Like CVE-2026-40886, it came from insufficient validation of user-supplied spec data. The vendor turned both fixes around quickly, and the patches for CVE-2026-40886 were published the same day as the advisory.

References

• GitHub Security Advisory GHSA-5jv8-h7qh-rf5p: Unchecked annotation parsing in pod informer crashes Argo Workflows controller
• Argo Workflows GitHub Repository
• Argo Workflows Releases
• CVE Record: CVE-2026-31892
• NVD Detail: CVE-2026-31892