CVE-2026-42154: Prometheus DOS Vulnerability

CVE-2026-42154 Overview

CVE-2026-42154 is a denial-of-service vulnerability in Prometheus, the open-source monitoring system and time series database. The remote read endpoint at /api/v1/read fails to validate the declared decoded length of a snappy-compressed request body before allocating memory. An unauthenticated attacker can send a small, crafted payload that triggers a large heap allocation per request. Under concurrent load, this exhausts available memory and crashes the Prometheus process. The flaw is classified as uncontrolled resource consumption [CWE-400] and affects Prometheus versions prior to 3.5.3 and 3.11.3.

Critical Impact

Unauthenticated remote attackers can crash Prometheus instances exposing the remote read endpoint, disrupting monitoring, alerting, and downstream observability pipelines.

Affected Products

• Prometheus versions prior to 3.5.3
• Prometheus versions prior to 3.11.3
• Deployments exposing the /api/v1/read remote read endpoint

Discovery Timeline

• 2026-05-04 - CVE-2026-42154 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-42154

Vulnerability Analysis

Prometheus exposes a remote read endpoint at /api/v1/read that accepts requests encoded with the snappy compression format. The handler reads the declared decoded length from the request and allocates a buffer of that size before validating whether the value is reasonable or matches the actual compressed payload. Because snappy supports high compression ratios, a small request body can declare a very large decoded length. The server honors the declared size and allocates a correspondingly large heap region for each incoming request.

When multiple such requests arrive concurrently, the cumulative memory pressure exceeds available system memory. The Prometheus process is terminated by the operating system out-of-memory killer or crashes when allocation fails. Attackers do not need credentials, since the endpoint accepts unauthenticated requests by default in many deployments.

Root Cause

The root cause is missing input validation on a length field controlled by the client. The remote read handler trusts the snappy-declared decoded length and allocates memory before decompression. A safe implementation would cap the maximum decoded size, stream-decompress with bounded buffers, or verify the declared length against a configured limit prior to allocation.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker sends crafted POST requests to /api/v1/read with a small snappy-compressed body that declares an oversized decoded length. Repeated concurrent requests inflate memory usage rapidly until the process crashes. The vulnerability does not affect confidentiality or integrity but produces a complete loss of availability for the monitoring service.

For implementation specifics, see the GitHub Security Advisory GHSA-8rm2-7qqf-34qm and the upstream fixes in Pull Request #18584 and Pull Request #18585.

Detection Methods for CVE-2026-42154

Indicators of Compromise

• Unexpected POST requests to /api/v1/read from untrusted source addresses, particularly with small body sizes that declare large decoded lengths.
• Sudden spikes in Prometheus process resident set size (RSS) followed by process restarts or out-of-memory kills.
• High concurrency of requests to the remote read endpoint from a single client or small set of clients.

Detection Strategies

• Monitor the Prometheus process metrics process_resident_memory_bytes and go_memstats_alloc_bytes for abnormal growth correlated with /api/v1/read traffic.
• Inspect HTTP access logs or reverse proxy logs for unauthenticated requests to /api/v1/read and alert on rates above expected baselines.
• Correlate Prometheus crash events and systemd restart entries with inbound request patterns to the remote read endpoint.

Monitoring Recommendations

• Forward Prometheus access logs and host-level memory metrics to a centralized analytics platform for correlation.
• Configure alerting on Prometheus process restarts and on prometheus_http_requests_total{handler="/api/v1/read"} rate anomalies.
• Track kernel oom-killer events on hosts running Prometheus to identify resource-exhaustion attempts.

How to Mitigate CVE-2026-42154

Immediate Actions Required

• Upgrade Prometheus to version 3.5.3 or 3.11.3 or later, depending on the deployed release branch.
• Restrict network access to /api/v1/read using firewall rules, network policies, or reverse proxy ACLs so only trusted clients can reach the endpoint.
• Place authentication and rate limiting in front of Prometheus through a reverse proxy such as NGINX, Envoy, or an API gateway.

Patch Information

The Prometheus maintainers patched this issue in v3.5.3 and v3.11.3. The fixes validate the declared snappy decoded length and bound buffer allocation in the remote read handler. Review the changes in Pull Request #18584 and Pull Request #18585 before deploying.

Workarounds

• Disable or block the /api/v1/read endpoint at the reverse proxy layer if remote read functionality is not required.
• Enforce per-client request body size limits and connection rate limits at the proxy to reduce amplification potential.
• Run Prometheus with constrained memory limits via cgroups or container resource limits to contain impact and trigger faster recovery.

# Example NGINX reverse proxy snippet to block /api/v1/read and cap body size
location = /api/v1/read {
    return 403;
}

client_max_body_size 1m;
limit_req_zone $binary_remote_addr zone=prom:10m rate=10r/s;

location /api/ {
    limit_req zone=prom burst=20 nodelay;
    proxy_pass http://prometheus_upstream;
}