Attack Chain

1. The attacker identifies an Argo Workflows instance with a publicly accessible /api/v1/events/ endpoint.
2. The attacker crafts an HTTP POST request targeting the /api/v1/events/ endpoint.
3. The attacker sets the Content-Length header of the request to a very large value (e.g., 1GB or more).
4. The attacker sends the malicious request with a large amount of arbitrary data as the request body.
5. The Argo Server receives the request and, within the WebhookInterceptor, calls io.ReadAll(r.Body), allocating memory to store the entire request body.
6. Due to the large request body, the Argo Server’s memory consumption increases significantly.
7. If the attacker sends a sufficiently large request, the Argo Server exhausts its available memory.
8. 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.MaxBytesReader or 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.