CVE-2026-96546: Gimp: gimp: one-byte out-of-bounds heap read in the uncompressed dds loader
A one-byte out-of-bounds heap read flaw was found in GIMP's DDS image loader. In loadlayer(), the bit-reader unconditionally increments the input pointer and fetches the next byte whenever the current byte's bits are exhausted. After processing the final pixel of an uncompressed DDS image, this logic dereferences exactly one byte beyond the allocated pixel buffer. The issue occurs with ordinary well-formed uncompressed DDS files, including files produced by GIMP itself, and was confirmed with AddressSanitizer in GIMP 3.2.6. The same code remained present in the main and gimp-3-2 branches when reported, and all versions are reported as affected. In a normal non-instrumented build, the adjacent byte is read into a local variable after the final pixel and is not known to influence the decoded image. No information disclosure or code-execution primitive was demonstrated, and a crash would require the byte immediately following the allocation to be inaccessible. This issue is distinct from CVE-2026-42170, which concerns a separate pitch-overflow write in the same file. A patch was available, but no fixed release had been identified at the time of reporting.
Other sources
A one-byte out-of-bounds heap read flaw was found in GIMP's uncompressed DDS image loader. When a user opens an uncompressed DDS image, the file-dds plug-in performs an unconditional one-byte look-ahead after processing the final pixel. This may cause the plug-in to crash if the byte immediately following the pixel buffer is inaccessible; no information disclosure or code execution has been demonstrated.
— MITRE
Affected Software
Event History
Frequently Asked Questions
What files and user actions can trigger the issue?
The flaw is triggered while loading an uncompressed DDS image, including ordinary well-formed files and DDS files produced by GIMP itself. Exploitation requires a user to open or otherwise load such an image; no attacker privileges are required.
How likely is this to have a practical security impact?
The out-of-bounds read is exactly one byte beyond the pixel buffer. In normal non-instrumented builds, that byte is stored in a local variable after the final pixel and is not known to affect the decoded image; no information disclosure or code-execution primitive was demonstrated. A crash requires the byte immediately following the allocation to be inaccessible.
Are installations affected by default, and which versions are vulnerable?
The affected code was present in GIMP 3.2.6 and remained in the main and gimp-3-2 branches when reported. All versions are reported as affected, and no fixed release had been identified at the time of reporting.
What can be done before a fixed release is available?
A patch was available at the time of reporting, so maintainers can apply or backport that patch where feasible. Otherwise, reduce exposure by avoiding the loading of untrusted uncompressed DDS files.
Is this the same issue as the DDS pitch-overflow vulnerability?
No. This is a separate one-byte out-of-bounds read in the DDS loader, whereas CVE-2026-42170 concerns a pitch-overflow write in the same file.