klauspost/compress EUVD-2026-110497

The application must decompress untrusted, attacker-controlled zstd data using a vulnerable klauspost/compress version (≤ 1.20.1) through zstd.DecodeAll or the streaming decoder - these are the standard, default decode paths, so no non-default configuration is needed. No authentication (PR:N), user interaction (UI:N), or special attack requirement (AT:N) is required, and the crash occurs against default decoder settings. The practical LIMITING factor is exposure rather than configuration: the attacker needs a reachable path that feeds untrusted zstd bytes into the decoder, and impact is confined to crashing the processing goroutine/process (availability only; no confidentiality or integrity effect). The specific trigger is a crafted two-block frame whose second block carries an FSE normalized count of 32768 that wraps to -32768 in int16 and reuses stale decode-table state from the first block - both blocks are required, as documented in the advisory.

This is a genuine but bounded availability risk - a reachable denial-of-service, not a code-execution or data-exposure flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with VA:H and VC:N/VI:N confirms the only impact is availability: a crafted ~27 KB two-block zstd frame makes DecodeAll and the streaming decoder panic with an out-of-range slice index that the caller cannot recover with normal error handling, so any service that decompresses attacker-controlled zstd input can be crashed. Signals mostly align on 'important but not emergency': EPSS is low (0.33%, 26th percentile), KEV status is NOT present (SSVC Exploitation: none), and SSVC Technical Impact is 'partial' - all consistent with a crash rather than full compromise. The counter-weight is SSVC Automatable: yes (the same crafted bytes trigger the panic deterministically and reliably, with no per-target tuning) and a confirmed working reproducer in the vendor advisory, which is why the vuln.today Decision label is 'this_week' rather than a lower tier. Note the tension to flag explicitly: EPSS/percentile are low and there is no evidence of active exploitation, yet a fully working PoC is public and the bug is trivially automatable - so the low EPSS reflects limited observed scanning, not low exploitability. Priority should be driven by exposure: schedule the update within the week (consistent with the Decision label), prioritizing any service that decompresses untrusted zstd at the network edge.

An attacker submits a crafted ~27 KB two-block zstd frame to any endpoint that decompresses untrusted zstd input using a vulnerable klauspost/compress version (≤ 1.20.1) via zstd.DecodeAll or the streaming decoder; the malformed Huffman-weight FSE table overflows the decode table and the goroutine panics, crashing the process. A complete, working reproducer is published in the GHSA advisory, so no exploit development is required. Exploitation is remote, unauthenticated (PR:N), requires no user interaction (UI:N), and is low-complexity (AC:L/AT:N), making it reliably repeatable against any default decoder configuration.