{"id":"CVE-2026-42294","aliases":["GHSA-jcc8-g2q4-9fxq","BIT-argo-workflows-2026-42294","GO-2026-5462"],"title":"Argo Vulnerable to Unauthenticated Memory Exhaustion (DoS) in Webhook Interceptor","summary":"Argo Vulnerable to Unauthenticated Memory Exhaustion (DoS) in Webhook Interceptor","severity":"high","cvss":7.5,"cvssVector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","vendor":"argoproj","product":"github.com/argoproj/argo-workflows/v3","ecosystem":"go","affected":["github.com/argoproj/argo-workflows/v3 < 3.7.14","github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5"],"patched":["github.com/argoproj/argo-workflows/v3 3.7.14","github.com/argoproj/argo-workflows/v4 4.0.5"],"published":"2026-05-04","updated":"2026-07-21","source":"OSV","sourceUrl":"https://osv.dev/vulnerability/GHSA-jcc8-g2q4-9fxq","references":[{"url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-jcc8-g2q4-9fxq"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-42294"},{"url":"https://github.com/argoproj/argo-workflows/commit/7abb4de6c3599e2d5d960ba4d5de4cf1df109965"},{"url":"https://access.redhat.com/security/cve/CVE-2026-42294"},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2468443"},{"url":"https://github.com/argoproj/argo-workflows"},{"url":"https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14"},{"url":"https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5"},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42294.json"}],"tags":["osv","go"],"epss":0.00607,"epssPercentile":0.47748,"ingestedAt":"2026-07-21T19:04:59.401Z","slug":"CVE-2026-42294","body":"## Overview\n\n**Severity:** Medium\n**Component:** Webhook Interceptor (`server/auth/webhook`)\n**Vulnerability Type:** Denial of Service (DoS)\n\n## Description\nThe 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.\n\n## Vulnerable Code\nIn `server/auth/webhook/interceptor.go`:\n```go\nfunc (i *WebhookInterceptor) addWebhookAuthorization(r *http.Request, kube kubernetes.Interface) error {\n    // ... basic checks ...\n    \n    // Vulnerability: Reads entire body into memory unconditionally\n    buf, _ := io.ReadAll(r.Body)\n    defer func() { r.Body = io.NopCloser(bytes.NewBuffer(buf)) }()\n    \n    // ... subsequent logic finds correct service account and secret ...\n    // ... verification happens later ...\n}\n```\nThe `io.ReadAll` call happens before the signature verification loop.\n\n## Impact\n- **Service Availability:** An attacker can crash the Argo Server, disrupting workflow execution and API access for all users.\n\n## PoC (Conceptual)\n1.  Target the webhook endpoint: `POST /api/v1/events/some-namespace`\n2.  Send a `Content-Length: 1000000000` (1GB) header.\n3.  Stream 1GB of random data.\n4.  Monitor server memory usage. It will spike until 1GB is allocated or the process crashes.\n\n## Recommendation\n1.  **Limit Body Size:** Enforce a strict limit on webhook body size (e.g., 10MB) using `http.MaxBytesReader`.\n2.  **Streaming Verification:** If possible, verify the signature in a streaming fashion or use a temporary file for large payloads (though typically webhooks are small).\n\n## Affected packages\n\n- `github.com/argoproj/argo-workflows/v3 < 3.7.14`\n- `github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `github.com/argoproj/argo-workflows/v3 3.7.14`\n- `github.com/argoproj/argo-workflows/v4 4.0.5`","depth":"twilight","depthScore":41,"depthScoreParts":{"impact":41.3,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}