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

CVE-2026-47247 is a heap information disclosure vulnerability in libheif caused by two chained bugs in grid image gap handling and uninitialized pixel plane allocation. It affects libheif versions up to and including 1.21.2, with the fix introduced in v1.22.0. The vulnerability allows a remote, unauthenticated attacker to leak process heap memory — including function pointers sufficient to defeat ASLR — by uploading a crafted AVIF/HEIC file to any server-side image processor. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The vulnerability chains two distinct bugs. Bug 1 (CWE-908/CWE-226): In pixelimage.cc:684, HeifPixelImage::ImageComponent::alloc() allocates pixel plane memory via new uint8_t[allocation_size] without zero-initialization. Due to stride alignment and rounded_size() padding, the allocation is deliberately oversized, and gap regions, stride padding, and height padding retain stale heap data. Bug 2 (CWE-682): In grid.cc:354, the grid coverage check uses integer division (grid.get_width() / grid.get_columns()), which truncates. For a 107px-wide grid with 9 columns, floor(107/9) = 11, so tiles cover columns 0–98, leaving column 99–106 (8 pixels) unwritten by copy_image_to. These gap pixels expose the uninitialized heap bytes from Bug 1 as renderable pixel values in the decoded output. A minimal 1,075-byte crafted AVIF file is sufficient to trigger the chain, requiring no authentication or user interaction (GitHub Advisory).

Successful exploitation leaks arbitrary heap memory — including freed dav1d DSP function pointers — as visible pixel values in transcoded JPEG, PNG, or WebP output. This enables a full ASLR bypass by reconstructing library base addresses from the 8 gap columns of the Y plane, which map to 8 bytes of a 64-bit pointer. Confirmed affected stacks include WordPress + Imagick, Sharp (Node.js, 43.6M weekly npm downloads), GNOME desktop via gdk-pixbuf, and pillow-heif; likely affected targets include imgproxy, Ruby on Rails Active Storage, Mastodon, Cloudinary, Shopify, GIMP, Krita, and darktable. No integrity or availability impact is present, but the confidentiality impact is high and the leaked data can facilitate further exploitation (GitHub Advisory).

1. Craft malicious AVIF file: Construct a minimal AVIF file (~1,075 bytes) containing a ftyp box (brand avif), a meta box with 9 tile items (av01, 11×64 each) and 1 grid item (grid, 107×64), a grid descriptor with 9 columns and output width 107 (so floor(107/9) = 11, leaving an 8-pixel gap), and 9 identical AV1 bitstreams (e.g., green tiles) in mdat.
2. Upload to target: Submit the crafted AVIF to any server-side image processor that uses libheif ≤ 1.21.2 (e.g., WordPress media upload, Sharp/libvips API endpoint, ImageMagick-backed service).
3. Download transcoded output: Retrieve the server-generated JPEG, PNG, or WebP thumbnail/output image.
4. Extract gap pixel data: Isolate the JPEG Y channel (lossless for this purpose in YCbCr encoding) and identify the 8 gap columns (columns 99–106 in the example). Each column corresponds to a different byte offset (mod 8) of the underlying heap data.
5. Reconstruct heap pointer: Assemble the 8 bytes from the gap columns into a 64-bit value. Match against a pre-computed table of known dav1d DSP function offsets across library versions.
6. Defeat ASLR: Subtract the matched offset from the reconstructed value to obtain the exact library base address, enabling further exploitation such as ROP chain construction.
7. Repeat if needed: Upload the crafted AVIF multiple times to increase the probability of the freed dav1d Dav1dDSPContext pointers landing in the reused heap region (GitHub Advisory).

• Network: Repeated uploads of small AVIF files (~1–2 KB) to image processing endpoints (e.g., WordPress /wp-admin/async-upload.php, Sharp API routes) followed immediately by downloads of the processed output; unusual volume of AVIF uploads from a single source IP.
• File System: Presence of crafted AVIF files with minimal ftyp/meta/mdat structure and grid descriptors where tile dimensions do not evenly divide the canvas dimensions; files significantly smaller than typical AVIF images for their declared resolution.
• Logs: Web server access logs showing POST requests uploading .avif files followed by GET requests for the corresponding processed thumbnails in rapid succession; repeated upload-download cycles from the same client.
• Process: Image processing worker processes (e.g., convert, vips, php-fpm) consuming unexpectedly low CPU for AVIF decoding (minimal tile content), combined with output images containing anomalous pixel columns at the right edge (GitHub Advisory).

Upgrade libheif to v1.22.0, which applies two fixes: (1) zero-initializes pixel plane allocations by changing new uint8_t[allocation_size] to new uint8_t[allocation_size]() in pixelimage.cc, and (2) replaces the integer-division grid coverage check with a multiplication-based check ((uint64_t)src_width * grid.get_columns() < grid.get_width()) in grid.cc to ensure tiles fully cover the canvas. SUSE has issued security update SUSE-SU-2026:2622-1 and openSUSE has issued openSUSE-SU-2026:20974-1 for their respective distributions. As a temporary workaround where upgrading is not immediately possible, restrict or disable AVIF/HEIC file upload and processing capabilities, or sanitize/reject AVIF files with grid images where tile dimensions do not evenly divide the canvas dimensions (GitHub Advisory, SUSE Advisory).

The vulnerability was reported by researcher rel-s, who noted the use of AI to accelerate research and PoC development while manually verifying all results. The advisory was published by farindk (a libheif maintainer) on May 19, 2026. The Solus Linux community discussed the issue in their weekly security roundup (Solus Forum), and the German Linux news site Pro-Linux.de covered it in their security advisories section (Pro-Linux). The researcher highlighted the severity of the downstream impact, noting that the chain is exploitable in no-permission, zero-click, over-the-air scenarios against widely deployed server-side image processing stacks (GitHub Advisory).