CVE-2026-42294: Argo Workflows DoS Vulnerability

CVE-2026-42294 Overview

CVE-2026-42294 is a denial-of-service vulnerability in Argo Workflows, an open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes. The flaw resides in the Webhook Interceptor, which reads the entire HTTP request body into memory before authenticating the request or validating its signature. The vulnerable code path is reachable through the publicly accessible /api/v1/events/ endpoint. An unauthenticated attacker can submit a request with a multi-gigabyte body to force the Argo Server to allocate excessive memory, triggering an Out-Of-Memory (OOM) crash. The issue affects all versions prior to 3.7.14 and 4.0.5 and is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact

Unauthenticated attackers can crash the Argo Server and disrupt Kubernetes workflow orchestration by sending a single oversized webhook payload.

Affected Products

• Argoproj Argo Workflows versions prior to 3.7.14
• Argoproj Argo Workflows versions prior to 4.0.5
• Deployments exposing the /api/v1/events/ webhook endpoint

Discovery Timeline

• 2026-05-09 - CVE-2026-42294 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-42294

Vulnerability Analysis

The vulnerability exists in server/auth/webhook/interceptor.go within the Argo Server. The interceptor needs the raw request body to verify the webhook signature before forwarding the request to the gRPC handler. To do this, it calls io.ReadAll(r.Body) with no upper bound on the number of bytes consumed. Because authentication and signature verification occur after the read completes, an attacker does not need any valid credentials or signing material to reach the allocation. Submitting a single request several gigabytes in size forces the Go runtime to allocate a buffer of equivalent size on the heap, exhausting available memory on the Argo Server pod and causing termination by the Kubernetes OOM killer.

Root Cause

The root cause is missing input size enforcement on a network-facing endpoint. The webhook interceptor trusts the client-supplied Content-Length and stream length while staging the body for later signature checks. Without a LimitReader, the read is bounded only by the attacker's willingness to send data and the server's available memory.

Attack Vector

Exploitation requires only network access to the Argo Server's /api/v1/events/ endpoint, which is intentionally exposed to receive webhooks from external systems. No authentication, no valid signature, and no user interaction are required. Repeated requests can keep the service in a crash loop, producing sustained denial of service for all workflow orchestration handled by the affected instance.

// Patch from server/auth/webhook/interceptor.go
		return fmt.Errorf("failed to get webhook clients: %w", err)
	}
	// we need to read the request body to check the signature, but we still need it for the GRPC request,
-	// so read it all now, and then reinstate when we are done
-	buf, _ := io.ReadAll(r.Body)
+	// so read it all now, and then reinstate when we are done.
+	// Limit to 2MB to prevent denial-of-service via oversized webhook payloads.
+	const maxWebhookSize = 2 * 1024 * 1024 // 2MB
+	buf, err2 := io.ReadAll(io.LimitReader(r.Body, maxWebhookSize+1))
+	if err2 != nil {
+		return fmt.Errorf("failed to read webhook request body: %w", err2)
+	}
+	if len(buf) > maxWebhookSize {
+		return fmt.Errorf("webhook request body exceeds maximum size of 2MB")
+	}
	defer func() { r.Body = io.NopCloser(bytes.NewBuffer(buf)) }()

Source: Argo Workflows commit 7abb4de. The patch wraps r.Body in an io.LimitReader capped at 2 MB and rejects requests that exceed the threshold before any further processing.

Detection Methods for CVE-2026-42294

Indicators of Compromise

• HTTP POST requests to /api/v1/events/ with Content-Length values in the hundreds of megabytes or gigabytes.
• Argo Server pods terminated with OOMKilled status in Kubernetes events.
• Repeated Argo Server pod restarts correlated with inbound traffic from a small set of source IPs.

Detection Strategies

• Inspect ingress and service-mesh access logs for unusually large request bodies targeting the Argo Server events endpoint.
• Alert on Argo Server container memory usage spikes that precede restart events.
• Correlate Kubernetes Reason=OOMKilled events on Argo Server workloads with traffic patterns on the webhook endpoint.

Monitoring Recommendations

• Track pod restart counts and memory saturation metrics for Argo Server deployments through Prometheus or equivalent.
• Forward ingress controller logs and Kubernetes audit logs to a centralized analytics platform for anomaly review.
• Establish a baseline for typical webhook payload sizes and alert on deviations.

How to Mitigate CVE-2026-42294

Immediate Actions Required

• Upgrade Argo Workflows to version 3.7.14 or 4.0.5, which enforce a 2 MB cap on webhook request bodies.
• Restrict network exposure of /api/v1/events/ to known webhook source ranges where operationally feasible.
• Configure Kubernetes resource requests and limits on the Argo Server pod to contain blast radius from memory spikes.

Patch Information

The fix is delivered in Argo Workflows v3.7.14 and Argo Workflows v4.0.5. The vendor advisory is published as GHSA-jcc8-g2q4-9fxq. The remediation introduces an io.LimitReader wrapper around the request body in the webhook interceptor and rejects payloads exceeding 2 MB before signature validation.

Workarounds

• Place a reverse proxy, ingress controller, or Web Application Firewall (WAF) in front of the Argo Server and enforce a maximum request body size on /api/v1/events/.
• Apply Kubernetes NetworkPolicy rules to restrict access to the webhook endpoint to specific upstream sources.
• Set strict memory limits on the Argo Server pod so an OOM event isolates the affected replica rather than destabilizing the node.

# Example NGINX ingress annotation to cap webhook request body size
kubectl annotate ingress argo-server \
  nginx.ingress.kubernetes.io/proxy-body-size=2m --overwrite