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’s SwatchBooker (SBZ) palette importer. The parser can leave the color model NULL, then still process <values> text and call strcmp(NULL, "srgb") in swatchbookerloadtext(), crashing the main GIMP process (palette import is not plug-in-isolated).

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 the GIMP XCF loader. Marking a channel as linked (PROPLINKED) stores a raw pointer in linkedchannels. A later PROPSELECTION on the same channel can destroy the object without removing that pointer. At end of load, gimpitemlistnamednew() dereferences the dangling pointer. The CVE-2025-14424 NULL guard does not stop a non-NULL dangling pointer, so this is an incomplete-fix bypass requiring a separate CVE. Reporters demonstrated reclaim of the freed block with attacker-controlled bytes.

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.

GIMP ships a plug-in (file-paa) that loads textures stored in the Bohemia Interactive PAA texture format. The loader computes the size of an intermediate decompression buffer with a 32-bit multiplication on the width × height × bytes-per-pixel value extracted from the file header. For specific 16-bit dimension pairs (e.g. width=32 768, height=32 769) the product overflows a 32-bit unsigned integer and wraps to a small value (131 072 bytes in the demonstrated case). GIMP allocates the wrapped (small) size, fills it with decompressed data, and then commits the buffer to a GEGL pixel buffer using the original (large) width × height rectangle. GEGL therefore reads gigabytes past the end of the heap allocation through memcpy, dereferencing unmapped memory and crashing the plug-in process. Triggering the vulnerability requires only that the user (or an automated preview/thumbnail consumer) open or peek at a crafted .paa file — for example by double-clicking the file, dragging it into GIMP, or by an indexer/file manager that runs GIMP's thumbnailer. The immediate observable effect is a reliable crash of the GIMP plug-in process (denial of service of the load operation, image data lost). Because the out-of-bounds read precedes the crash and copies adjacent heap memory into pixel data committed to a GEGL buffer, the bug also has the potential to disclose contents of the plug-in's heap through any pixel data that is rendered, exported, or copied to the clipboard before the read walks off the end of mapped memory. CWE-190 (Integer Overflow or Wraparound) leading to CWE-125 (Out-of-bounds Read).

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

Finding 7. plug-ins/common/hot.c, pluginCore() (~429–443, 618). Same wrapped allocation vs internal/GEGL consumer extent. ASan WRITE. Vector: apply Hot filter on oversized image (filter path, not file parser). CVSS tentative: 6.3 (AC:H).

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.