CVE-2026-46599
Description
The TIFF decoder does not place a limit on the size of PackBits-compressed data. A maliciously-crafted image can exploit this to cause a small image (both in terms of pixel width/height and encoded size) to make the decoder decode large amounts of compressed data.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A missing size limit in the Go x/image/tiff PackBits decoder allows a crafted TIFF to decompress excessive data, causing OOM.
Vulnerability
The TIFF decoder in the golang.org/x/image library, specifically in the PackBits decompression path, does not impose a limit on the amount of compressed data it will process. An attacker can create a malicious TIFF file that is small in pixel dimensions and encoded size but contains PackBits markers that cause the decoder to decompress a very large volume of data. This affects all versions prior to v0.41.0 of golang.org/x/image [1][2][3].
Exploitation
An attacker must deliver the crafted TIFF file to a program that uses the vulnerable library to decode it (e.g., an image viewer, web service, or document parser). No special authentication or elevated privileges are required; the attack triggers during normal image decoding. The attacker supplies a small TIFF image with PackBits-compressed strips or tiles that contain literal-run and copy-run instructions designed to expand to gigabytes of output data [1][3].
Impact
Successful exploitation causes uncontrolled memory consumption (out-of-memory) in the process performing the TIFF decode. This leads to a denial of service (availability loss). There is no indication that the excessive allocation can be used for code execution or information disclosure; the impact is limited to resource exhaustion [1][3].
Mitigation
The fix was released in version v0.41.0 of golang.org/x/image on 2026-05-21 [1]. Users should update to this version or later. If updating the module is not immediately possible, programs can mitigate by validating TIFF files before decoding (e.g., rejecting files with unusual compression ratios) or by running the decoding process in a resource-constrained environment. The issue is tracked as GO-2026-5032; there is no known KEV listing [2][3].
AI Insight generated on May 29, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
1fe8ae458fe5etiff: limit PackBits decompression output size
3 files changed · +8 −4
tiff/compress.go+6 −2 modified@@ -15,11 +15,12 @@ type byteReader interface { } // unpackBits decodes the PackBits-compressed data in src and returns the -// uncompressed data. +// uncompressed data. The output size is limited to lim bytes to prevent +// decompression bombs. // // The PackBits compression format is described in section 9 (p. 42) // of the TIFF spec. -func unpackBits(r io.Reader) ([]byte, error) { +func unpackBits(r io.Reader, lim int64) ([]byte, error) { buf := make([]byte, 128) dst := make([]byte, 0, 1024) br, ok := r.(byteReader) @@ -54,5 +55,8 @@ func unpackBits(r io.Reader) ([]byte, error) { } dst = append(dst, buf[:1-code]...) } + if int64(len(dst)) > lim { + return nil, FormatError("PackBits: decompressed data too large") + } } }
tiff/reader.go+1 −1 modified@@ -756,7 +756,7 @@ func Decode(r io.Reader) (img image.Image, err error) { d.buf, err = readBuf(r, d.buf, blockMaxDataSize) r.Close() case cPackBits: - d.buf, err = unpackBits(io.NewSectionReader(d.r, offset, n)) + d.buf, err = unpackBits(io.NewSectionReader(d.r, offset, n), blockMaxDataSize) default: err = UnsupportedError(fmt.Sprintf("compression value %d", d.firstVal(tCompression))) }
tiff/reader_test.go+1 −1 modified@@ -73,7 +73,7 @@ func TestUnpackBits(t *testing.T) { "\xaa\xaa\xaa\x80\x00\x2a\xaa\xaa\xaa\xaa\x80\x00\x2a\x22\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa", }} for _, u := range unpackBitsTests { - buf, err := unpackBits(strings.NewReader(u.compressed)) + buf, err := unpackBits(strings.NewReader(u.compressed), 1<<20) if err != nil { t.Fatal(err) }
Vulnerability mechanics
Root cause
"Missing output size limit in PackBits decompression allows a small compressed TIFF to expand to a very large buffer."
Attack vector
An attacker crafts a small TIFF image (small pixel dimensions and small encoded file size) that uses PackBits compression. The PackBits format allows a single control byte to repeat a byte many times, so a small compressed payload can expand to a very large output. The decoder's `unpackBits` function had no output size limit, enabling a 2 MB TIFF to decompress to 745 MB (372× amplification). No authentication or special network position is required; the victim need only decode the malicious image [patch_id=3107111].
Affected code
The vulnerability is in the `unpackBits` function in `tiff/compress.go` and its call site in `tiff/reader.go`. The `unpackBits` function had no output size limit, while other decompression paths (LZW, Deflate, CCITT) used `readBuf` which enforces a limit. The PackBits path bypassed `readBuf` entirely [patch_id=3107111].
What the fix does
The patch adds a `lim int64` parameter to `unpackBits` and checks `int64(len(dst)) > lim` after each iteration, returning a `FormatError` if the limit is exceeded. The call site in `reader.go` passes `blockMaxDataSize` as the limit, matching the existing limit used by `readBuf` for other compression formats. This ensures PackBits decompression is bounded the same way as LZW, Deflate, and CCITT decompression [patch_id=3107111].
Preconditions
- inputVictim must decode a TIFF image using PackBits compression
- authNo authentication or special privileges required
- networkAttacker can deliver the image over any channel (web upload, email, etc.)
Generated on May 29, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.