CVE-2026-116591: compress zstd: Panic on two-block frames
compress provides various compression algorithms. Prior to 1.20.2, the zstd DecodeAll and streaming decoder paths can panic when a crafted two-block frame reaches huff0.ReadTable with an FSE normalized count of 32768 that readNCount stores in int16 as -32768. The wrapped count allows buildDtable to retain stale fse.Scratch decode-table state from the prior block, and nextFast then derives an out-of-range state and indexes beyond the table instead of returning a decode error. Both blocks are required to preserve and then reuse the stale state, allowing untrusted zstd input to crash an application. This issue is fixed in version 1.20.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
compress zstdto a version that resolves this vulnerability.Fixed in 1.20.2
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using github.com/klauspost/compress versions before 1.20.2 are exposed if they process untrusted Zstandard input through the zstd DecodeAll or streaming decoder paths.
What does an attacker need to trigger the problem?
An attacker needs to supply a crafted two-block Zstandard frame. The first block preserves stale FSE decode-table state, and the second block reuses it to cause an out-of-range table access.
What is the practical impact?
The crafted input can panic the application rather than producing a decode error, resulting in an application crash.
How can I determine whether my application is affected?
Check whether the application depends on github.com/klauspost/compress at a version earlier than 1.20.2 and whether it decodes untrusted Zstandard data using DecodeAll or the streaming decoder.
What should be done to remediate the issue?
Upgrade github.com/klauspost/compress to version 1.20.2. Until upgrading, avoid passing untrusted Zstandard input to the affected decoder paths where possible.