Which versions of Argo Workflows are affected by CVE-2026-42294?

Argo Workflows servers are vulnerable to unauthenticated denial-of-service attacks via the public webhook endpoint, allowing remote attackers to crash the service by sending large requests without…. A patch is available.

How to fix or mitigate CVE-2026-42294?

Within 24 hours: Identify all Argo Workflows deployments and determine internet exposure of the `/api/v1/events/` endpoint. Within 7 days: Apply vendor-released patch to all affected Argo Workflows instances (consult vendor advisory for specific patched version numbers). Within 30 days: Conduct post-patch validation and implement network segmentation to restrict webhook endpoint access to trusted sources only.

Argo Workflows CVE-2026-42294

Q: What is the CVSS score of CVE-2026-42294?

CVE-2026-42294 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: 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. EPSS exploitation probability: 0.0%.

HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-05-04 https://github.com/argoproj/argo-workflows

GHSA-jcc8-g2q4-9fxq

Kubernetes Denial Of Service

8.2

CVSS 4.0 · Vendor: https://github.com/argoproj/argo-workflows

Severity by source

Vendor (https://github.com/argoproj/argo-workflows) PRIMARY

8.2 HIGH

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

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (https://github.com/argoproj/argo-workflows).

CVSS VectorVendor: https://github.com/argoproj/argo-workflows

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

May 09, 2026 - 04:29 vuln.today

v2 (cvss_changed)

Re-analysis Queued

May 09, 2026 - 04:22 vuln.today

cvss_changed

CVSS changed

May 09, 2026 - 04:22 NVD

8.2 (HIGH)

Source Code Evidence Fetched

May 04, 2026 - 21:01 vuln.today

Analysis Generated

May 04, 2026 - 21:01 vuln.today

DescriptionCVE.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.