CVE-2026-18090: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-18090 is a heap out-of-bounds read vulnerability in gdk-pixbuf, a widely used GNOME image loading library. The flaw exists in the uncompress() function within gdk-pixbuf/io-icns.c, which handles RLE-encoded Apple Icon Image (.icns) file decompression without validating source buffer boundaries. Affected products include Red Hat packages gdk-pixbuf2, glycin-loaders, gnome-tour, librsvg2, loupe, papers, snapshot, gdk-pixbuf2-xlib, and cppcheck; specific version ranges have not been published. The vulnerability was reported on August 18, 2026, and publicly disclosed on September 8, 2026. It carries a CVSS v3.1 base score of 6.1 (Medium) (Red Hat Advisory, Github Advisory).

The root cause is an out-of-bounds read (CWE-125) in the uncompress() function in gdk-pixbuf/io-icns.c (lines 192–246 upstream). The function decompresses RLE-encoded ICNS icon data but is never passed a bound on the source buffer; it loops until it has produced size*size decoded pixels, consuming however many source bytes the RLE stream claims it needs, with no validation that per-iteration reads (the tag byte at data[0], the repeat-value byte at data[1], or run bytes at data[i+1]) remain within the allocated block. The load_icon() function holds the correct block size (isize, derived from plen = blocklen - sizeof(IcnsBlockHeader)) but never forwards it to uncompress(). All four RLE-compressed ICNS block types (is32 16×16, il32 32×32, ih32 48×48, it32 128×128) are affected; ic08/ic09 (256×256) blocks use JPEG 2000 and are not affected. Exploitation requires a local attacker to supply a specially crafted .icns file (e.g., an il32 block with a declared blocklen covering only the header and zero payload bytes) that a user then opens (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation can result in a denial of service (application crash via segmentation fault) or limited information disclosure by leaking adjacent heap bytes into the decoded pixel data. Confidentiality impact is low — sensitive data such as memory addresses or heap contents from adjacent allocations may be exposed, potentially aiding ASLR bypass for chaining with further exploits. Integrity is not impacted. The scope is limited to the affected application process and does not directly enable lateral movement or remote code execution (Red Hat Advisory, Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.167% (6th percentile), indicating a low probability of exploitation in the near term. Exploitation is not automatable and requires user interaction to open a malicious .icns file (Github Advisory, Red Hat Advisory).

1. Craft malicious .icns file: Create a specially crafted Apple Icon Image file containing an RLE-compressed block (e.g., il32 for 32×32 icons) where the declared blocklen in the IcnsBlockHeader covers only the header itself, leaving zero payload bytes — causing uncompress() to immediately read past the end of the allocated buffer.
2. Deliver the file: Distribute the malicious .icns file to the target via email attachment, file share, web download, or embedding it in an archive, relying on social engineering to prompt the user to open it.
3. Trigger parsing: The victim opens the .icns file using an application that relies on gdk-pixbuf for image loading (e.g., a GNOME file manager thumbnail preview, image viewer, or any GTK application that renders icons).
4. Heap out-of-bounds read occurs: The uncompress() function in io-icns.c reads past the end of the mapped/allocated ICNS data, either crashing the process (DoS) or leaking adjacent heap bytes into the decoded pixel buffer.
5. Achieve objective: Depending on heap layout, the attacker may observe a crash (DoS) or, in a more targeted scenario, recover leaked heap data (e.g., memory addresses or sensitive values) from the decoded image output to facilitate further exploitation (Red Hat Bugzilla, Red Hat Advisory).

• File System: Unexpected or suspicious .icns files in user download directories, email attachments, or temporary folders, particularly those with abnormally small file sizes relative to their declared icon dimensions.
• Logs: Application crash logs or core dumps from gdk-pixbuf-consuming processes (e.g., nautilus, eog, loupe, librsvg2-linked applications) with segmentation fault signals (SIGSEGV) or heap corruption messages referencing io-icns.c or uncompress().
• Process: Unexpected termination of GNOME desktop components or image viewer processes immediately after opening or previewing an .icns file; repeated crashes of thumbnail generation services (e.g., gnome-thumbnail-factory).

No vendor patch with a specific fixed version number has been published as of the disclosure date. Red Hat's recommended mitigations are: (1) do not open untrusted .icns files from unknown or unverified sources, and (2) disable ICNS image format support in gdk-pixbuf if it is not required by the environment. Users should monitor Red Hat errata for gdk-pixbuf2 package updates addressing this issue. The upstream bug is tracked at the GNOME GitLab issue #308 (Red Hat Advisory, Github Advisory).

Red Hat classified this as a Low impact flaw, noting that exploitation requires local access and user interaction to process a malicious file, limiting its practical severity. The vulnerability was credited to researcher Alexandru Hossu. No significant broader media coverage or notable community commentary has been identified beyond standard vulnerability database entries (Red Hat Advisory).