CVE-2026-42154

What it actually does

The Prometheus remote read API endpoint, /api/v1/read, accepts snappy-compressed request bodies. In affected versions before 3.5.3 and 3.11.3, Prometheus does not validate the declared decoded length before allocating memory for decompression. A remote unauthenticated attacker can send a small crafted request that causes Prometheus to allocate an extremely large heap buffer. Repeated or concurrent requests can exhaust process or host memory, causing the Prometheus process to crash or be killed by the operating system. The impact is denial of service; there is no known confidentiality or integrity impact from the flaw itself.

Why it matters to the business

Successful exploitation can take down monitoring and alerting visibility by crashing Prometheus, which may delay incident detection, capacity monitoring, SLO reporting, and operational response. Because exploitation is network-accessible, unauthenticated, and low-complexity, any internet-exposed or broadly reachable Prometheus remote read endpoint is higher risk even though current EPSS is low, there is no known KEV listing, and no public exploit maturity is reported. Organizations that rely on Prometheus for production alerting should treat remediation as operationally important because loss of monitoring can mask other outages or attacks.

How an attack unfolds

An attacker first identifies a reachable Prometheus HTTP API. They then target the remote read endpoint at /api/v1/read with a malformed or abusive snappy-compressed request body whose declared decoded length is much larger than the actual payload. Vulnerable Prometheus versions allocate memory based on that untrusted declared size before sufficiently validating it. A single request may cause a large heap allocation, and many concurrent requests can rapidly consume available memory. Once memory is exhausted, Prometheus may terminate due to a Go runtime out-of-memory condition, be killed by the Linux OOM killer, crash, or enter a restart loop under a service manager or orchestrator. The attacker does not need credentials if the endpoint is reachable without authentication.

How to fix it

Upgrade Prometheus to a patched release: version 3.5.3 or later on the 3.5.x line, or version 3.11.3 or later on the 3.11.x line. If using container images, rebuild and redeploy from patched Prometheus images rather than only restarting existing containers. If immediate upgrade is not possible, restrict access to the Prometheus HTTP API and especially /api/v1/read using network controls, reverse proxy authentication, mTLS, firewall rules, VPN-only access, or Kubernetes NetworkPolicies. Disable or block remote read access where it is not required. Add request body size limits, concurrency limits, and rate limits at an ingress controller, load balancer, or reverse proxy. Ensure service managers or orchestrators have sane restart policies, memory limits, and alerting so crashes are visible, but do not treat restarts alone as remediation.

How to confirm the fix worked

Confirm the running Prometheus version reports 3.5.3 or later, or 3.11.3 or later, using the Prometheus web UI, /api/v1/status/buildinfo, container image tags, package inventory, or binary version output. Verify that unauthenticated users cannot reach /api/v1/read from untrusted networks. Review reverse proxy, ingress, firewall, and Kubernetes NetworkPolicy rules to confirm the endpoint is not broadly exposed. In staging, perform safe negative testing with oversized request-body controls and confirm the proxy rejects abusive payloads before they reach Prometheus. Monitor Prometheus process memory after upgrade or mitigation to confirm malformed remote read traffic no longer causes abnormal heap growth or crashes.

Typical attack path

1. Discover a reachable Prometheus web/API service, commonly on port 9090 or behind a reverse proxy.
2. Confirm that the /api/v1/read remote read endpoint is reachable.
3. Send a crafted snappy-compressed remote read request with an excessive declared decoded length.
4. Repeat the request or send concurrent requests to amplify memory pressure.
5. Cause Prometheus heap growth, host memory exhaustion, process crash, OOM kill, or repeated restarts.
6. Maintain denial of service by continuing requests until the endpoint is patched, restricted, or rate-limited.

How to detect it

To determine whether exploitation may already have occurred, review reverse proxy, ingress controller, load balancer, firewall, and Prometheus access logs for unusual POST traffic to /api/v1/read, especially bursts, high concurrency, repeated 4xx/5xx responses, small request bodies followed by service instability, or requests from unfamiliar IP addresses. Correlate those events with Prometheus process memory spikes, abrupt restarts, container OOMKilled events, Linux OOM killer messages, Go runtime out-of-memory errors, systemd restart events, Kubernetes pod restarts, and gaps in Prometheus time-series ingestion or alert evaluation. Useful sources include NGINX/Apache/Envoy/HAProxy/Traefik access logs, Kubernetes events, container runtime logs, journald/syslog, Prometheus service logs, host kernel logs, EDR process telemetry, and metrics for process_resident_memory_bytes, go_memstats_heap_alloc_bytes, process_start_time_seconds, and up for Prometheus itself. Because this is a denial-of-service vulnerability, indicators are more likely to show crash-and-restart behavior and abusive endpoint access than persistent malware artifacts.

• POST /api/v1/read
• /api/v1/read
• Content-Encoding: snappy
• Content-Type: application/x-protobuf
• fatal error: runtime: out of memory
• runtime: out of memory
• out of memory: Killed process
• prometheus invoked oom-killer
• Killed process prometheus
• OOMKilled
• Back-off restarting failed container
• go_memstats_heap_alloc_bytes
• process_resident_memory_bytes
• process_start_time_seconds

What your security team should do

• Prioritize patching any internet-facing or broadly reachable Prometheus instances to 3.5.3+ or 3.11.3+.
• Inventory Prometheus deployments, including containers, Helm charts, appliances, and bundled observability stacks, for versions prior to 3.5.3 and 3.11.3.
• Restrict /api/v1/read to trusted remote-read clients only; do not expose it anonymously to the internet or general internal networks.
• Place Prometheus behind authentication and network allowlisting where feasible.
• Add reverse proxy or ingress controls for maximum request body size, request rate, and concurrent requests to /api/v1/read.
• Alert on Prometheus restarts, OOM kills, sudden resident memory growth, and spikes in POST requests to /api/v1/read.
• Review recent logs for evidence of abnormal remote read traffic and memory exhaustion, especially because the issue has been public for about 100 days.
• Do not rely on the current low EPSS or lack of KEV status as a reason to leave monitoring infrastructure exposed.