Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| github.com/prometheus/prometheus | go | >= 0.306.0, < 0.311.3 | 0.311.3 |
| github.com/prometheus/prometheus | go | < 0.305.2 | 0.305.2 |
| github.com/prometheus/prometheus | go | >= 1.0.0-rc.0, <= 2.5.0 |
Miggo AIRoot Cause AnalysisThe vulnerability lies in the DecodeReadRequest function within storage/remote/codec.go, which handles incoming data for Prometheus's remote read API. The core issue is an uncontrolled resource consumption vulnerability (CWE-400). The function would directly attempt to decompress snappy-encoded request bodies without first checking the size of the data that would result from decompression. An unauthenticated attacker could exploit this by sending a small, specially crafted request that, when decompressed, would require a massive amount of memory to be allocated. This is known as a 'compression bomb' attack. The vulnerable snappy.Decode call would trigger this large allocation, and multiple such requests could easily exhaust the server's memory, causing the Prometheus process to crash and resulting in a denial of service. The analysis of the patch commits (327393517041139946b96d03c90252e6f5fe4063 and a75e3011d9f0ebfd3b9adf4e41d7d377fb4cdc29) shows that the fix involves adding a preliminary step: the code now uses snappy.DecodedLen to determine the expected size of the decompressed data and compares it against a hard limit (decodeReadLimit). If the expected size exceeds the limit, the request is rejected before any large memory allocation can occur, thus neutralizing the vulnerability.
