Argo Workflows: Unauthenticated Memory Exhaustion (DoS) in Webhook Interceptor
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.7.14, 4.0.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: yes
- Technical impact: partial
Summary
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to versions 3.7.14 and 4.0.5, the Webhook Interceptor loads the entire request body into memory before authenticating the request or verifying its signature. This occurs on the /api/v1/events/ endpoint, which is publicly accessible (albeit intended for webhooks). An attacker can send a request with an extremely large body (e.g., multiple gigabytes), causing the Argo Server to allocate excessive memory, potentially leading to an Out-Of-Memory (OOM) crash and denial of service. This issue has been patched in versions 3.7.14 and 4.0.5.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: poc · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- argoproj argo-workflows
fixed in 3.7.14; From 4.0.0 · fixed in 4.0.5
- github.com/argoproj/argo-workflows/v3Go
fixed in 3.7.14
- github.com/argoproj/argo-workflows/v4Go
From 4.0.0 · fixed in 4.0.5
- github.com/argoproj/argo-workflowsGo
All versions
- github.com/argoproj/argo-workflows/v2Go
All versions