Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain workflow-submit RBAC in cluster
-
DeliveryCraft pod-gc-strategy annotation without slash
-
ExploitApply Workflow with poisoned podMetadata
-
ExecutionInformer parses annotation, parts[1] panics
-
PersistController crash-loops on every restart
-
ImpactAll workflow processing halted
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Array index validation
|
| Exploitation Conditions | Exploitation requires the attacker to be able to create a Kubernetes pod/Workflow in a cluster running an affected Argo Workflows controller and to set the pod annotation workflows.argoproj.io/pod-gc-strategy to a value containing no '/' character (e.g. 'NoSlash') - that malformed annotation is itself the trigger. This corresponds to CVSS PR:L: the attacker needs workflow-submission or pod-create RBAC, so a fully external unauthenticated attacker cannot reach it directly. No user interaction, no non-default feature flag, and no special platform are needed - the vulnerable podGCFromPod() code path is always active. Limiting factors: clusters where only trusted operators can submit workflows sharply reduce real-world risk, and the effect is availability-only with no data disclosure or code execution; the primary practical constraint is possession of workflow/pod-creation rights in the controller's watched namespaces. |
| Impact | The signals are internally consistent and point to a genuine but bounded availability threat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, base 7.7 High) fits well: network-reachable, low complexity, but requiring some privilege (PR:L) because the attacker must be authorized to create a Workflow or pod carrying the annotation, with a scope change since one workflow's pod takes down the shared controller, and pure availability impact (no confidentiality or integrity loss). EPSS is 0.04% (12th percentile) and there is no CISA KEV listing, so widespread opportunistic exploitation is unlikely; however a public PoC exists and reproduction is trivial, so the barrier is low for anyone who already holds submit access. SSVC records Automatable: no (a valid annotation must be crafted and submitted, not mass-sprayed) and Technical Impact: partial. Net assessment: a real, high-priority DoS for multi-tenant Argo clusters where workflow submission is delegated to semi-trusted users, but a low-priority issue where only trusted operators can submit workflows. No conflicting data was identified; the key nuance is that the impact is availability-only despite the network attack vector. |
| Exploit ScenarioDerived | A tenant with permission to submit workflows in a shared Argo namespace applies a Workflow whose podMetadata sets workflows.argoproj.io/pod-gc-strategy to a value with no slash, such as 'NoSlash'. Within seconds the controller reads the annotation via the pod informer, panics on parts[1], and drops into CrashLoopBackOff, halting all workflow processing for every tenant until an operator locates and deletes the offending pod. A copy-paste PoC manifest is published in the GHSA advisory, so no exploit development is required. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 24, 2026
Denial of service in the Argo Workflows controller (versions 3.6.5 through 4.0.4, plus the 3.7.0-rc1 through 3.7.12 pre-releases) lets any user able to submit a workflow crash-loop the entire controller by attaching a malformed workflows.argoproj.io/pod-gc-strategy pod annotation that contains no '/' separator, triggering an out-of-range index panic in an informer goroutine that sits outside the controller's recover() scope. Because the poisoned pod persists across restarts, the controller enters CrashLoopBackOff and halts all workflow processing cluster-wide until the pod is manually deleted. A working proof-of-concept manifest is published in the GHSA advisory (SSVC exploitation status: poc), but there is no evidence of active exploitation and EPSS is very low at 0.04%.
RemediationAI
Vendor-released patch: upgrade to Argo Workflows 4.0.5 or 3.7.14, which add bounds checking before accessing the split annotation. Note that the 3.6.x line has no fixed release identified in the source data (fixed-in: None for the >= 3.6.5, <= 3.6.19 range), so 3.6.x operators should plan a migration to 3.7.14 or later rather than expecting a 3.6.x hotfix - review CRD and behavior changes for that minor-version jump against the GHSA advisory (https://github.com/argoproj/argo-workflows/security/advisories/GHSA-5jv8-h7qh-rf5p). Until patched, reduce exposure by tightening Kubernetes RBAC so untrusted tenants cannot create Workflows or set podMetadata annotations, and consider an admission-control policy (Kyverno or OPA Gatekeeper) that rejects or sanitizes any pod whose workflows.argoproj.io/pod-gc-strategy annotation value does not contain a '/'; the trade-off is added webhook maintenance and the risk of blocking legitimate custom GC-strategy values. If the controller is already crash-looping, the immediate recovery is to manually delete the poisoned pod (kubectl delete pod) so it stops re-triggering the panic on every restart.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 7 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Argo Workflows is a CNCF container-native workflow engine that orchestrates parallel jobs on Kubernetes via a central controller that watches pods through a client-go informer. The root cause is CWE-129 (Improper Validation of Array Index): the podGCFromPod() function in workflow/controller/pod/controller.go splits the pod-gc-strategy annotation value on '/' and unconditionally reads parts[1], so any value lacking a slash produces a length-1 slice and panics with 'index out of range [1] with length 1'. The panic fires inside the pod informer's commonPodEvent handler, which runs in a separate informer goroutine that is not wrapped by the controller's top-level recover(), so instead of being contained the failure terminates the whole controller process. The regression was introduced by upstream change #14129 and back-ported into the 3.6.x line via #14263. The affected component is cpe:2.3:a:argoproj:argo-workflows.
Know when Argo Workflows gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
Network-reachable but requires workflow-submit RBAC (PR:L); a single crafted pod crashes the shared controller (S:C) with availability-only impact (A:H, C:N/I:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
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.
Executive ViewAI
A vulnerability in Argo Workflows controller (versions 3.6.5-4.0.4 and pre-releases 3.7.0-rc1-3.7.12) could allow authorized users to crash the platform and halt all workflow processing cluster-wide by submitting malformed configuration data. While exploit code is publicly available, exploitation likelihood is low and requires workflow submission access; however, the operational impact-complete workflow processing outage until manual recovery-warrants immediate patching.
Apply vendor patch. As interim mitigations pending patch deployment: restrict workflow submission permissions to trusted users, monitor controller logs for annotation parsing errors, and establish procedures for emergency pod recovery.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
More in Argo Workflows
View allPrivilege escalation in Argo Workflows before 3.7.15 and 4.0.6 lets a low-privileged user who can submit Workflows bypas
Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 are vulnerable to a Zip Slip path traversal during artif
Authorization bypass in Argo Workflows (2.9.0 through 4.0.1 and 3.7.x before 3.7.11) lets any user permitted to submit W
Cross-namespace data disclosure in Argo Workflows 4.1.0 through 4.1.3 lets an authenticated user who holds only namespac
Malicious tar archives can escape Argo Workflows' artifact extraction directory and overwrite /var/run/argo/argoexec ins
Information disclosure in Argo Workflows before 4.0.2 and 3.7.11 lets any unauthenticated client read WorkflowTemplates
Stored cross-site scripting in Argo Workflows (CNCF Kubernetes workflow engine) before 3.6.17 and 3.7.8 lets any authent
In Argo Workflows through 3.1.3, if EXPRESSION_TEMPLATES is enabled and untrusted users are allowed to specify input par
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated m
Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 write the artifact repository credentials held in the wo
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated h
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated m
Same weakness CWE-129 – Improper Validation of Array Index
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
EUVD-2026-25267
GHSA-5jv8-h7qh-rf5p
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB