CVE-2025-0453

What it actually does

The vulnerability is an uncontrolled resource consumption denial-of-service condition in the GraphQL API. An unauthenticated or otherwise API-capable attacker can submit large batched GraphQL requests that repeatedly ask the service to enumerate runs for an experiment. Each request consumes application worker capacity and backend query resources; enough concurrent or batched requests can exhaust available MLflow/Argo-exposed service workers, causing legitimate API and UI requests to queue, time out, or fail. The issue is fixed for github.com/argoproj/argo-workflows/v3 in versions 3.5.13 and 3.6.2.

Why it matters to the business

Successful exploitation can make affected workflow or experiment-tracking functionality unavailable, disrupting machine-learning operations, CI/CD-style workflow execution, experiment review, and dependent automation. The CVSS score is moderate and the issue is not listed in CISA KEV and has no reported ransomware association, but the EPSS score indicates non-trivial likelihood of exploitation compared with many vulnerabilities, and public availability for over a year increases the chance that scanning or opportunistic abuse may occur against exposed endpoints.

How an attack unfolds

An attacker first identifies an exposed affected service with a reachable GraphQL endpoint. They then craft GraphQL requests that batch many similar queries together, focusing on expensive operations such as repeatedly requesting all runs associated with an experiment. Because the vulnerable implementation does not adequately limit request complexity, batch size, pagination, or per-client resource use, the service allocates workers and backend resources to process the requests. By sending enough large or concurrent requests, the attacker keeps all available workers busy. Once worker capacity is saturated, normal users and automated systems experience slow responses, HTTP errors, timeouts, or complete inability to use the application until traffic stops, workers recover, or the service is restarted and protected.

How to fix it

Upgrade affected github.com/argoproj/argo-workflows/v3 deployments to a fixed release: 3.5.13 for the 3.5.x line or 3.6.2 for the 3.6.x line. If immediate upgrade is not possible, reduce exposure of the GraphQL endpoint by placing it behind authentication, VPN, trusted network controls, or an application gateway; apply rate limits and request-size limits to /graphql; disable GraphQL batching if supported; enforce query depth, complexity, and timeout limits; and ensure expensive list operations require pagination and bounded result sizes. Also tune worker pools and backend timeouts so abusive requests fail quickly rather than monopolizing all workers.

How to confirm the fix worked

Confirm the running package or container uses github.com/argoproj/argo-workflows/v3 version 3.5.13, 3.6.2, or later in the applicable release line. Verify software composition analysis, dependency lockfiles, container image manifests, and runtime version output all agree. Test that /graphql is no longer publicly reachable unless explicitly required, and that authentication, rate limiting, request body size limits, GraphQL batch limits, query complexity limits, and timeouts are enforced. In a controlled non-production environment, attempt a large batched GraphQL request and confirm it is rejected, throttled, or terminated without exhausting all service workers or causing unrelated requests to fail.

Typical attack path

1. Discover an internet- or network-accessible affected application endpoint.
2. Confirm that the /graphql endpoint is reachable and accepts GraphQL POST requests.
3. Construct a large batched GraphQL payload containing repeated expensive queries for experiment runs.
4. Send the payload repeatedly or concurrently from one or more clients.
5. Consume all available application workers and backend query capacity.
6. Cause legitimate UI/API requests to hang, time out, or fail until resources recover or mitigations are applied.

How to detect it

To determine whether exploitation has already occurred, review HTTP access logs, reverse proxy logs, WAF logs, application logs, container logs, and infrastructure metrics for unusual bursts of POST requests to /graphql, especially large request bodies, repeated batched GraphQL payloads, requests with long processing times, and many similar queries from the same source. Correlate these events with application symptoms such as worker exhaustion, high CPU or database load, increased memory use, request queue growth, HTTP 5xx/504 responses, service restarts, readiness/liveness probe failures, and user reports of timeouts. If request bodies are logged or available from WAF telemetry, look for repeated GraphQL operations querying runs or experiment-related objects in a single request. Because this is a denial-of-service issue, indicators are more likely to be traffic patterns and resource-exhaustion artifacts than persistent files, malware, or host changes.

• POST /graphql
• "/graphql"
• "graphql"
• "query"
• "runs"
• "experiment"
• "experiments"
• "504 Gateway Timeout"
• "503 Service Unavailable"
• "upstream timed out"
• "context deadline exceeded"
• "request body too large"

What your security team should do

• Prioritize upgrade to github.com/argoproj/argo-workflows/v3 3.5.13 or 3.6.2, especially for externally reachable or shared multi-user deployments.
• Inventory all deployments, containers, and downstream applications that expose or bundle the affected GraphQL functionality.
• Restrict access to /graphql to trusted users and networks; avoid exposing it directly to the public internet.
• Add application-layer rate limits, request-size limits, and GraphQL query complexity or batch controls for /graphql.
• Create monitoring and alerting for spikes in POST requests to /graphql, elevated request duration, worker saturation, HTTP 429/500/502/503/504 responses, and backend query load.
• Review historical logs for signs of repeated large GraphQL requests and correlate with availability incidents or service restarts.
• Document operational runbooks for quickly blocking abusive clients, scaling capacity temporarily, and restarting exhausted workers if service degradation occurs.