A flaw was found in GIMP. Opening a crafted XCF that selects a path and then fails to load that path can cause a use-after-free in the main process, leading to a crash and potentially arbitrary code execution.

A flaw was found in the GIMP XCF loader. PROPSELECTEDPATH stores a raw pointer in the selected-paths list. If path parsing later fails, the object is destroyed without removing that pointer. End-of-load gimpimagesetselectedpaths() then dereferences the dangling pointer. Reporters demonstrated reclaim with attacker-controlled file bytes.

A flaw was found in GIMP XCF text-layer handling. Parasite payloads can be stored as exact file-sized heap copies without a NUL terminator, then processed with unbounded C-string APIs in gimptextfromparasite(). This over-reads heap memory in the main process; leaked bytes can appear as layer text / errors and persist into a re-saved XCF. A crafted file can also crash GIMP.

A flaw was found in GIMP XCF text-layer handling. Parasite payloads can be stored as exact file-sized heap copies without a NUL terminator, then processed with unbounded C-string APIs in gimptextfromparasite(). This over-reads heap memory in the main process; leaked bytes can appear as layer text / errors and persist into a re-saved XCF. A crafted file can also crash GIMP.

A flaw was found in GIMP. Importing a crafted SBZ palette without a color-model attribute can cause a NULL pointer dereference during string comparison, resulting in denial of service of the GIMP application.

A flaw was found in GIMP. The XCF loader can leave a dangling pointer in the linked-channels list when a linked channel is later destroyed via a selection property. Opening a crafted XCF file can cause a use-after-free in the main GIMP process, leading to a crash and potentially arbitrary code execution.

A flaw was found in GIMP. The PSD thumbnail resource loader performs a BGR-to-RGB channel swap with a fixed 3-byte stride and does not verify that the JPEG thumbnail is RGB. A crafted grayscale PSD thumbnail can cause a heap out-of-bounds read and write in the plug-in process, leading to a crash and potentially arbitrary code execution when the victim browses or opens the file.

A flaw was found in the GIMP PSD plug-in thumbnail loader. When a PSD embeds a grayscale JPEG thumbnail, the BGR-to-RGB swap in loadresource1033() uses a hard-coded 3-byte stride without checking the JPEG component count, reading and writing past the heap buffer. The overflow length is controlled by the file. This can be triggered during thumbnail generation in the file chooser, without fully opening the image. This is distinct from CVE-2026-92248 (thumbnail allocation integer overflow).

A flaw was found in GIMP. An integer overflow occurs in the file-pvr plug-in when calculating memory buffer sizes for image dimensions. By tricking a user into opening or previewing a specially crafted PowerVR (.pvr) file, an attacker can trigger a heap-based buffer overflow, potentially leading to arbitrary code execution or a Denial of Service (DoS) via an application crash.

GIMP ships a plug-in (file-pvr) that loads textures stored in the PowerVR (.pvr) texture format. Inside pvrdecodecompressed (the helper used for the four compressed-VQ data formats), the size of the destination pixel buffer is computed in 32-bit int arithmetic from the file's declared width, height, and a derived component count. For attacker-chosen 16-bit dimension pairs (e.g. width = 32 768, height = 32 769) and an alpha-bearing pixel mode (MODEARGB1555 or MODEARGB4444), the product width × height × ncomponents overflows INTMAX and wraps to a small positive value — 131 072 bytes for the demonstrated trigger. The function allocates that much memory and then writes into it using the original (large) width × ncomponents row stride, producing a heap-based buffer overflow write at the very first row past the allocated boundary. The dispatcher in loadimage does perform a bounds check (mipmapwidth >= MAXTWIDDLESIZE and mipmapheight >= MAXTWIDDLESIZE), but for dataformat == MODECOMPRESSEDMIPMAP (or MODESMALLVQMIPMAP) that check applies only to the auto-derived mipmap dimensions, not to the file's width/height values that are passed unchecked into pvrdecodecompressed. This is the gap that makes the integer overflow reachable. Triggering the vulnerability requires only that the user open or thumbnail a crafted .pvr file in GIMP — for example by double-clicking the file, dragging it into GIMP, or via any indexer that invokes GIMP's file-thumbnailer backend. The bug is a heap write (CWE-787) of attacker-influenced bytes off the end of an undersized buffer; the writes are short (1 byte at a time per component) but their starting offset and surrounding contents are derived from data that the attacker fully controls (the codebook bytes in the PVR file). This makes the bug a strong candidate for heap corruption / arbitrary write primitive that may be developed into remote code execution. At minimum it provides reliable denial-of-service via plug-in crash.

A flaw was found in GIMP. An attacker can cause a Denial of Service (DoS) or potentially disclose sensitive memory contents by convincing a user to open or preview a specially crafted Bohemia Interactive (PAA) texture file. Due to an integer overflow when calculating image dimensions during file decompression, the application allocates an undersized memory buffer. Subsequent processing reads memory past the buffer boundary, terminating the plug-in process unexpectedly.

A flaw was found in GIMP. The XCF loader processes image-simulation-intent and image-simulation-bpc parasites without ensuring the parasite data is present before dereferencing it. Opening a specially crafted XCF file with a zero-size simulation parasite can cause a NULL pointer dereference and crash the GIMP application.

A heap-based buffer overflow was found in GIMP’s Hot color filter plug-in. For very large images, a pixel buffer is allocated using overflowing 32-bit width height (and related) arithmetic while the filter’s pixel access path uses the true image size, after integer overflow in the allocation size

A heap-based buffer overflow was found in GIMP’s raw data export plug-in. When exporting very large images, gmalloc() sizing based on overflowing width height bytes-per-pixel can allocate far less memory than GEGL reads or writes during export, following integer overflow

Finding 6. plug-ins/common/file-raw-data.c, exportimage() (~1510–1512). PoC example W=32770, H=32768 (RGBA). ASan WRITE via geglbufferiteratereadsimple. CVSS tentative: 6.3 (AC:H).

A heap-based buffer overflow was found in GIMP’s PCX export plug-in. For images with extremely large width and height, buffer allocation uses overflowing 32-bit width height arithmetic while subsequent GEGL operations use the full extent, after integer overflow in size calculation

Finding 5. plug-ins/common/file-pcx.c, exportimage() (~1192–1195). SIGSEGV/heap WRITE on export. CVSS tentative: 6.3 (AC:H).

A heap-based buffer overflow was found in GIMP’s GIF export plug-in. Exporting an image with very large width and height can cause 32-bit overflow when computing the pixel buffer size. The plug-in allocates a buffer based on the wrapped value while GEGL writes using the true image extent, rooted in integer overflow

Finding 4. plug-ins/common/file-gif-export.c, exportimage() (~1053–1057). Same allocation vs GEGL extent mismatch. ASan WRITE. Vector: GIF export on oversized image. CVSS tentative: 6.3 (AC:H).

A heap-based buffer overflow was found in GIMP’s DICOM export plug-in. When exporting an image with extremely large width and height, the export path allocates a buffer using a 32-bit width height (and bytes-per-pixel) product that can overflow. GEGL then writes the full uncompressed extent into the undersized buffer, after integer overflow in the allocation size

Finding 3. plug-ins/common/file-dicom.c, exportimage() (~1649–1652). Wrapped width height bpp allocation; GEGL write exceeds buffer. SIGSEGV/ASan WRITE. Vector: export to DICOM on very large image (multi‑GB scale), not a small malicious download alone. CVSS tentative: AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H (6.3).

A heap-based buffer overflow was found in GIMP’s DirectDraw Surface (DDS) loader. When loading a crafted DDS image, buffer sizes derived from width, height, and pitch can be computed using 32-bit arithmetic that overflows. The allocated buffer is too small for the amount of pixel data written through GEGL, following integer overflow in size calculations. This may allow heap corruption and, in the worst case, arbitrary code execution in the context of the GIMP process.

Same upstream issue, Finding 2. plug-ins/common/ddsread.c, readdds() / loadlayer() (~428–1313): pitch/buffer sizing with wrapped width height (and related fields); GEGL writes past heap buffer. ASan-confirmed heap-buffer-overflow write. Vector: load crafted DDS file. Survives prior DDS fix CVE-2026-42170 (commit 7dff816) per reporter. CVSS tentative: AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8).

A flaw was found in GIMP’s X cursor (XMC) thumbnail loader. When GIMP generates a thumbnail for a crafted XMC file, it allocates a pixel buffer using a width height size computed in 32-bit signed arithmetic. If that product overflows, the allocation is smaller than the true image extent. A subsequent GEGL buffer read uses the unwrapped dimensions and performs an out-of-bounds read on the heap, after integer overflow in the size calculation. This can crash GIMP or corrupt process memory.

A flaw was found in GIMP. When processing a specially crafted GIMPressionist preset file, the plug-in does not properly validate vector indices before writing into fixed-size arrays. This can lead to an out-of-bounds write, corrupting memory. An attacker could exploit this by convincing a user to load a malicious preset file, potentially causing a crash or enabling arbitrary code execution.

A flaw was found in GIMP's GIMPressionist plug-in. When loading a preset file, presets.c parses an attacker-controlled index with atoi() in setorientvector() and setsizevector() and uses it to write into pcvals.orientvectors[] and pcvals.sizevectors[] without checking that the index is within the fixed array bounds (MAXORIENTVECT and MAXSIZEVECT, 50 entries each). A crafted preset with an out-of-range or negative index causes writes past those arrays, corrupting memory. This issue can be triggered by convincing a user to load a specially crafted GIMPressionist preset, potentially leading to a crash or arbitrary code execution in the context of the user running GIMP. This is distinct from CVE-2026-90947, which addressed a similar missing bound check in the Lighting Effects plug-in. The issue is present in GIMP 3.2.6; a bounds check was added on the main branch.

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.

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.

An out-of-bounds heap read flaw was found in GIMP's TIM image loader. When a crafted 4bpp TIM image has a palette large enough to enable promotetorgb, the loader creates an RGBA layer but allocates the row buffer using the smaller indexed-image size. The file-tim plug-in allocates width times two bytes for a two-row buffer, while geglbufferset() interprets the same buffer as RGBA data and reads width times eight bytes. This reads width times six bytes beyond the row buffer for every pair of rows. Adjacent heap contents are copied into the decoded image as pixel data, potentially exposing process memory if the resulting image is saved or shared; the invalid read may also crash the plug-in. The issue was reproduced with AddressSanitizer and differential images in GIMP 3.2.6, and the same code was present in the main branch. All versions are reported as affected. This is distinct from CVE-2026-40916, whose fix enlarged the row buffer for indexed layers but did not account for promotetorgb, and CVE-2026-59089, which addressed separate palette-size arithmetic. A patch was available, but no fixed release had been identified at the time of reporting.

An out-of-bounds heap read flaw was found in GIMP's TIM image loader. When a crafted 4bpp TIM image has a palette large enough to enable promotetorgb, the loader creates an RGBA layer but allocates the row buffer using the smaller indexed-image size. The file-tim plug-in allocates width times two bytes for a two-row buffer, while geglbufferset() interprets the same buffer as RGBA data and reads width times eight bytes. This reads width times six bytes beyond the row buffer for every pair of rows. Adjacent heap contents are copied into the decoded image as pixel data, potentially exposing process memory if the resulting image is saved or shared; the invalid read may also crash the plug-in. The issue was reproduced with AddressSanitizer and differential images in GIMP 3.2.6, and the same code was present in the main branch. All versions are reported as affected. This is distinct from CVE-2026-40916, whose fix enlarged the row buffer for indexed layers but did not account for promotetorgb, and CVE-2026-59089, which addressed separate palette-size arithmetic. A patch was available, but no fixed release had been identified at the time of reporting.