Argo Workflows Webhook Interceptor Vulnerable to Unauthenticated Memory Exhaustion (CVE-2026-42294)
Argo Workflows is vulnerable to a denial-of-service (DoS) attack due to unbounded memory allocation in the Webhook Interceptor component.
Argo Workflows is vulnerable to a denial-of-service (DoS) attack (CVE-2026-42294) due to unbounded memory allocation in the Webhook Interceptor. The vulnerability resides in the server/auth/webhook/interceptor.go component, specifically within the /api/v1/events/ endpoint. This endpoint, intended for webhook integrations, reads the entire request body into memory without proper size limits, leading to potential memory exhaustion. An attacker can exploit this vulnerability by sending a crafted request with an extremely large body, causing the Argo Server to allocate excessive memory and potentially crash, resulting in a denial of service. Affected versions include Argo Workflows versions prior to 3.7.14 and versions 4.0.0 up to 4.0.5.
Attack Chain
- The attacker identifies an Argo Workflows instance with a publicly accessible
/api/v1/events/endpoint. - The attacker crafts an HTTP POST request targeting the
/api/v1/events/endpoint. - The attacker sets the
Content-Lengthheader of the request to a very large value (e.g., 1GB or more). - The attacker sends the malicious request with a large amount of arbitrary data as the request body.
- The Argo Server receives the request and, within the
WebhookInterceptor, callsio.ReadAll(r.Body), allocating memory to store the entire request body. - Due to the large request body, the Argo Server’s memory consumption increases significantly.
- If the attacker sends a sufficiently large request, the Argo Server exhausts its available memory.
- The Argo Server process crashes due to an Out-Of-Memory (OOM) error, leading to a denial of service.
Impact
Successful exploitation of this vulnerability results in a denial-of-service condition, disrupting workflow execution and API access for all users of the Argo Workflows instance. The Argo Server crashes, making it unavailable until restarted. This impacts service availability and potentially causes data loss if workflows are interrupted during execution. The number of victims depends on the number of Argo Workflows instances exposed and targeted by attackers.
Recommendation
- Enforce a strict limit on webhook body size (e.g., 10MB) using
http.MaxBytesReaderor similar mechanisms within your ingress controller or reverse proxy to prevent oversized requests from reaching the Argo Server. - Upgrade Argo Workflows to version 3.7.14 or 4.0.5 or later to patch CVE-2026-42294 and mitigate the risk of denial-of-service attacks.
- Monitor memory usage of the Argo Server process and set up alerts for unusually high memory consumption to detect potential exploitation attempts.
Detection coverage 2
Detect Large HTTP POST Requests to Argo Webhook Endpoint
mediumDetects HTTP POST requests with a large Content-Length header targeting the Argo Workflows webhook endpoint, indicating a potential DoS attempt.
Detect HTTP 413 Errors on Argo Webhook Endpoint
lowDetects HTTP 413 Payload Too Large errors on the Argo Workflows webhook endpoint, which may indicate attempts to exploit the DoS vulnerability.
Detection queries are kept inside the platform. Get full rules →