Live › vulnerability › CVE-2026-116591
Go to dashboardThe compress Go library's zstd decoder can be made to panic by a crafted two-block frame, because a wrapped Huffman table count leaves stale decode state that is read out of bounds. An attacker who supplies untrusted zstd input can crash any application that decodes it.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 22:25 UTC. All times on this page are UTC.
Go services that decode zstd data from untrusted sources (uploads, network streams, package or log inputs) using the zstd DecodeAll or streaming decoder are exposed. Programs that only handle trusted zstd data or do not use zstd decoding can skip it.
No product ranges from the sources yet.
go list -m github.com/klauspost/compress in the project to see the version in use (the module that provides compress algorithms; confirm the module path against the go.mod file).klauspost/compress and check whether it is a direct or transitive dependency.1.20.2 or later with go get github.com/klauspost/[email protected] followed by go mod tidy.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-116591")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.