CVE-2026-40886: Argo Workflows DoS Vulnerability

CVE-2026-40886 Overview

A denial of service vulnerability exists in Argo Workflows, an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. 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.

Critical Impact

This vulnerability enables an authenticated attacker to crash the Argo Workflows controller through a malformed annotation, creating a persistent denial of service condition that requires manual intervention to resolve.

Affected Products

• Argo Workflows versions 3.6.5 through 4.0.4
• Argo Workflows versions prior to 3.7.14 (in the 3.x branch)
• Argo Workflows versions prior to 4.0.5 (in the 4.x branch)

Discovery Timeline

• 2026-04-23 - CVE CVE-2026-40886 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-40886

Vulnerability Analysis

This vulnerability stems from improper validation of array bounds within the Argo Workflows controller. The podGCFromPod() function processes the workflows.argoproj.io/pod-gc-strategy annotation without proper validation of the input structure, leading to an uncontrolled array index access.

The critical aspect of this vulnerability is its persistence mechanism. When a malformed pod annotation triggers the panic, the problematic pod remains in the cluster. On controller restart, the pod informer immediately processes the same malicious pod, triggering another panic. This creates a crash loop that effectively takes down the entire Argo Workflows infrastructure until manual intervention removes the offending pod.

The CWE-129 (Improper Validation of Array Index) classification accurately reflects the root cause—the code fails to verify that array indices derived from user-controlled input are within valid bounds before accessing array elements.

Root Cause

The root cause is an unchecked array index access in the podGCFromPod() function within the pod informer component. When processing the workflows.argoproj.io/pod-gc-strategy annotation, the function parses the annotation value and uses it to index into an array without first validating that the index falls within the array's bounds. A malformed annotation value can specify an out-of-bounds index, triggering a Go runtime panic.

Compounding this issue is the architectural placement of the vulnerable code within an informer goroutine. Go's informer pattern operates outside the typical controller reconciliation loop, meaning the standard recover() mechanisms that protect controller logic do not apply to panics in this code path.

Attack Vector

An attacker with permissions to create or modify workflow pods in the Kubernetes cluster can exploit this vulnerability by applying a malformed workflows.argoproj.io/pod-gc-strategy annotation to a pod. The attack requires only low-level privileges (the ability to create pods with custom annotations) but can impact the entire Argo Workflows deployment serving multiple users and namespaces.

The exploitation mechanism involves creating a workflow pod with a specifically crafted annotation value that causes the array index bounds check to fail. Once this pod exists in the cluster, any controller restart will immediately crash again when the informer processes the malicious pod, creating a persistent denial of service condition.

Detection Methods for CVE-2026-40886

Indicators of Compromise

• Repeated crash loops in the Argo Workflows controller pod with panic-related exit codes
• Kubernetes events showing CrashLoopBackOff status for the argo-workflows-controller deployment
• Controller logs containing Go panic stack traces referencing the podGCFromPod() function
• Workflow pods with unusual or malformed workflows.argoproj.io/pod-gc-strategy annotation values

Detection Strategies

• Monitor Argo Workflows controller logs for panic stack traces, particularly those mentioning podGCFromPod or array index operations
• Implement Kubernetes admission controllers to validate annotation values on workflow pods before creation
• Set up alerting on controller pod restart counts exceeding normal thresholds within short time windows
• Audit workflow pod annotations for unexpected or malformed pod-gc-strategy values using kubectl queries

Monitoring Recommendations

• Configure Prometheus alerts for Argo Workflows controller pod restart metrics exceeding baseline
• Implement log aggregation with pattern matching for Go panic signatures in controller logs
• Monitor Kubernetes events in the Argo Workflows namespace for deployment availability issues
• Set up SentinelOne Singularity Cloud Security for Kubernetes workload protection and anomaly detection

How to Mitigate CVE-2026-40886

Immediate Actions Required

• Upgrade Argo Workflows to version 4.0.5 or later (for 4.x deployments) or version 3.7.14 or later (for 3.x deployments)
• Audit existing workflow pods for malformed workflows.argoproj.io/pod-gc-strategy annotations
• If experiencing crash loops, identify and delete pods with malformed annotations before restarting the controller
• Implement RBAC restrictions to limit which users can create pods with arbitrary annotations

Patch Information

The vulnerability is fixed in Argo Workflows versions 4.0.5 and 3.7.14. The patches add proper bounds checking to the podGCFromPod() function before accessing array elements based on annotation values. Organizations should upgrade to these patched versions as soon as possible. For additional details, refer to the GitHub Security Advisory.

Workarounds

• Implement a Kubernetes ValidatingAdmissionWebhook to reject pods with malformed pod-gc-strategy annotations
• Use OPA Gatekeeper or Kyverno policies to validate workflow pod annotations before admission
• Restrict pod creation permissions to trusted service accounts only through Kubernetes RBAC
• Monitor for and automatically delete pods with suspicious annotation patterns before controller restarts

# Identify pods with pod-gc-strategy annotations for review
kubectl get pods -A -o json | jq -r '.items[] | select(.metadata.annotations["workflows.argoproj.io/pod-gc-strategy"] != null) | "\(.metadata.namespace)/\(.metadata.name): \(.metadata.annotations["workflows.argoproj.io/pod-gc-strategy"])"'