Argo Workflows CVE-2026-42294
HIGH
GHSA-jcc8-g2q4-9fxq
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (https://github.com/argoproj/argo-workflows).
CVSS VectorVendor: https://github.com/argoproj/argo-workflows
Lifecycle Timeline
5DescriptionCVE.org
Severity: Medium Component: Webhook Interceptor (server/auth/webhook) Vulnerability Type: Denial of Service (DoS)
Description
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.
Vulnerable Code
In server/auth/webhook/interceptor.go:
func (i *WebhookInterceptor) addWebhookAuthorization(r *http.Request, kube kubernetes.Interface) error {
// ... basic checks ...
// Vulnerability: Reads entire body into memory unconditionally
buf, _ := io.ReadAll(r.Body)
defer func() { r.Body = io.NopCloser(bytes.NewBuffer(buf)) }()
// ... subsequent logic finds correct service account and secret ...
// ... verification happens later ...
}The io.ReadAll call happens before the signature verification loop.
Impact
- Service Availability: An attacker can crash the Argo Server, disrupting workflow execution and API access for all users.
PoC (Conceptual)
- Target the webhook endpoint:
POST /api/v1/events/some-namespace - Send a
Content-Length: 1000000000(1GB) header. - Stream 1GB of random data.
- Monitor server memory usage. It will spike until 1GB is allocated or the process crashes.
Recommendation
- Limit Body Size: Enforce a strict limit on webhook body size (e.g., 10MB) using
http.MaxBytesReader. - Streaming Verification: If possible, verify the signature in a streaming fashion or use a temporary file for large payloads (though typically webhooks are small).
AnalysisAI
Memory exhaustion crashes Argo Workflows server via unauthenticated multi-gigabyte webhook requests to the publicly accessible /api/v1/events/ endpoint. The Webhook Interceptor's io.ReadAll call allocates unbounded memory before signature verification, enabling remote attackers to trigger out-of-memory (OOM) conditions without authentication or credentials. Vendor-released patches enforce a 2MB body size limit via io.LimitReader. Publicly available exploit code exists (conceptual proof-of-concept published in GitHub security advisory GHSA-jcc8-g2q4-9fxq). No active exploitation confirmed by CISA KEV at time of analysis, but the low attack complexity (CVSS AV:N/AC:L/PR:N) and public PoC create immediate risk for internet-exposed Argo Workflows deployments.
Technical ContextAI
Argo Workflows is a container-native workflow engine for orchestrating parallel jobs on Kubernetes. The vulnerable component is the Webhook Interceptor in the Argo Server (server/auth/webhook/interceptor.go), which handles incoming webhook events on the /api/v1/events/{namespace} REST API endpoint. This endpoint accepts POST requests from external webhook providers (GitHub, GitLab, etc.) to trigger workflows. The root cause (CWE-770: Allocation of Resources Without Limits or Throttling) lies in the addWebhookAuthorization function calling Go's io.ReadAll(r.Body) unconditionally before any authentication, authorization, or signature verification. The function reads the entire HTTP request body into a byte buffer in memory to enable subsequent HMAC signature validation against stored secrets. However, because io.ReadAll has no size bounds, an attacker can specify arbitrary Content-Length headers (e.g., 1GB+) and stream corresponding payload data, forcing the Go runtime to allocate RAM until system memory is exhausted or the container's memory limit triggers an OOM kill. Affected versions span both major release branches: Argo Workflows v3 (all versions prior to 3.7.14) and v4 (versions 4.0.0 through 4.0.4). CPE identifiers confirm impact on pkg:go/github.com/argoproj/argo-workflows/v3 and pkg:go/github.com/argoproj/argo-workflows/v4.
RemediationAI
Upgrade immediately to Argo Workflows v3.7.14 (for v3.x deployments) or v4.0.5 (for v4.x deployments) as documented in vendor releases at https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14 and https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5. The fix implements a strict 2MB maximum body size using Go's io.LimitReader wrapper before the io.ReadAll call, returning HTTP 403 errors for oversized payloads as shown in commit 7abb4de6c3599e2d5d960ba4d5de4cf1df109965. For environments unable to upgrade immediately, implement network-layer compensating controls: configure ingress controllers or reverse proxies (nginx, Envoy, AWS ALB) to enforce maximum request body size limits of 2MB specifically for the /api/v1/events/* endpoint pattern (example nginx: client_max_body_size 2m; in location block). Note this workaround requires careful routing configuration to avoid blocking legitimate API traffic on other endpoints and does not address the underlying code vulnerability. Additionally, restrict network access to the webhook endpoint using Kubernetes NetworkPolicies or cloud security groups to allow only known webhook provider IP ranges (GitHub's published IP blocks, GitLab SaaS IPs, etc.), reducing attack surface from arbitrary internet hosts. This network restriction provides defense-in-depth but should not replace patching, as compromised webhook providers or MITM attacks could still exploit the vulnerability. Monitor Argo Server pod memory consumption metrics and configure Kubernetes resource limits as a detection mechanism (not prevention) for exploitation attempts.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same 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 |
Share
External POC / Exploit Code
Leaving vuln.today