CVE-2026-48029: Two grid-decode bugs in libheif

Both bugs live in libheif/image-items/grid.cc in the function ImageItem_Grid::decode_grid_tile. The relevant excerpt from libheif 1.21.2 is short:

uint32_t idx = ty * m_grid_spec.get_columns() + tx;

assert(idx < m_grid_tile_ids.size());                  // line 586  -- F2 sink

heif_item_id tile_id = m_grid_tile_ids[idx];            // line 588  -- F2 OOB read
std::shared_ptr<const ImageItem> tile_item =
    get_context()->get_image(tile_id, true);            // line 589
if (auto error = tile_item->get_item_error()) {         // line 590  -- F1 NULL deref
  return error;
}

Four consecutive lines, two distinct memory-safety bugs.

F1 - NULL pointer deref on a missing grid tile reference

A HEIF grid is a derived image: a virtual item that says "to draw me, take these N tile items, lay them out in an R×C grid." The tile items are pointed to via an iref dimg (derived-image reference). At parse time the only consistency check is that dimg.size() == rows * cols. A file that declares a perfectly-sized dimg list whose entries point at item ids that do not exist - or at ids that exist but are not decodable images (an Exif metadata item, for example) - passes that check fine.

At decode time, HeifContext::get_image(id, only_images) returns an empty std::shared_ptr for any id that does not resolve to an image item in the registry. The very next line in decode_grid_tile calls tile_item->get_item_error() on it - a member call through a null shared_ptr. SIGSEGV. The dereferenced address is 0x0 plus a small constant vtable offset, so this is a deterministic crash, not a controlled write.

The sibling derived-image classes all do the missing null-check:

The fix is structurally identical to the pattern at overlay.cc:339: five lines, one if (!tile_item) return Error{...};. That is what upstream commit e1b97646 shipped.

F2 - uint32 underflow into an unchecked vector index

F2 is the more interesting bug. The end of the chain is the line two above F1, on grid.cc:586-588: a uint32_t idx computed from the tile coordinates, an assert(idx < m_grid_tile_ids.size()), and then an unchecked std::vector::operator[] access.

In a debug build the assert fires and the process aborts. In a release build compiled with -DNDEBUG - the configuration typical distribution packages use - the assert is compiled to nothing and the next line walks a vector with an attacker-influenced index. ASAN reports:

==NN==ERROR: AddressSanitizer: SEGV on unknown address 0x610400000e00
==NN==The signal is caused by a READ memory access.
    #0 ImageItem_Grid::decode_grid_tile          grid.cc:588:26
    #1 ImageItem_Grid::decode_compressed_image   grid.cc:224
    #2 ImageItem::decode_image                   image_item.cc:747
    #3 HeifContext::decode_image                 context.cc:1404
    #4 heif_image_handle_decode_image_tile       heif_tiling.cc:108
SUMMARY: AddressSanitizer: SEGV grid.cc:588:26 in
  ImageItem_Grid::decode_grid_tile(...)

ASAN reports SEGV rather than heap-buffer-overflow only because idx is so large that m_grid_tile_ids.data() + idx*4 overshoots into unmapped memory. The bug class is still the same: an unchecked vector::operator[] access with an attacker-influenced index. The bytes read are a heif_item_id (4 bytes), used downstream as a lookup key in HeifContext::get_image().

The huge index comes from a uint32 underflow upstream. ImageItem::transform_requested_tile_position_to_original_tile_position performs subtractions like num_columns - 1 - tile_y and num_rows - 1 - tile_x on caller-supplied coordinates, against the pre-rotation grid extents. The caller's (tile_x, tile_y) are documented as being in the post-rotation (displayed) grid. When the rotation is 90° or 270° and rows ≠ columns, the displayed grid has its dimensions swapped relative to the file grid, and a legal post-rotation coordinate can exceed the smaller pre-rotation extent. The subtraction underflows to ~UINT32_MAX, the underflowed value flows into decode_grid_tile, the idx = ty * cols + tx arithmetic produces an enormous index, and the vector access walks off the heap.

This is a CWE-191 (integer underflow) feeding a CWE-125 (out-of-bounds read). The primitive is not trivially-leaking into an external observer - the 4 bytes read are consumed as a hash-map lookup key - but it is structurally a memory-safety bug, not a robustness assertion. The advisory states exactly that scope and nothing more.

Why two builds matter

The same source code, the same input file, two different categorisations depending on whether -DNDEBUG is set:

Release-style builds with assertions disabled are what most downstream packages ship, so that configuration is what defines the security envelope. A fuzzing setup that only runs against debug-with-asserts will look at the SIGABRT from F2 and file a hardening PR. The release-build re-run is what turns it into a memory-safety report.

Two fixes, not one

The patch above shows the F1 null check and the F2 sink-side runtime bounds check. A third commit (e523ec0b, authored by Dirk Farin) is the structurally correct F2 source-side fix - process transformations on the tiling upfront so the arithmetic operates on post-rotation dimensions, then reject out-of-range caller coordinates before any subtraction. The in-code comment matches the advisory almost word-for-word: the displayed grid has its columns and rows swapped relative to the file; using the file dims both let out-of-range coordinates through and produced unsigned underflows inside the inverse-rotation formulas.

Attribution and parallel discovery

An attribution note worth making explicit: two of the three upstream commits in this area - e1b97646 and 518bd95f - were authored by Anthony Hurtado with a "Found by: AFL++ fuzzing with custom harness" trailer. My private report and reproducers were sent to the maintainer before I knew those commits existed; when the maintainer eventually checked my PoC against v1.22.0, he confirmed it was already fixed - probably from his own fuzzer runs. The cleanest framing is parallel discovery and overlapping validation, not a claim that my report alone caused every upstream patch. The third commit, e523ec0b - the structurally correct F2 source-side fix - was authored by the maintainer (Dirk Farin) the following day, and its in-code comment matches the underflow scenario described in my advisory almost word-for-word. The advisory itself (GHSA-6x5f-qchq-cxqv) was accepted, published, and credited to me as reporter after I mirrored the report to GitHub on 2026-05-20.

The realistic blast radius is wider than for the average codec bug, because both bugs live in the container layer - which runs before any codec back-end - and are reachable through libheif's most-used public APIs. Any consumer that opens a malicious HEIF or HEIC file and asks libheif to decode either the primary image or a single tile reaches the vulnerable function.

Exploitability

• F1 - reliable DoS. Any consumer that calls heif_decode_image or heif_image_handle_decode_image_tile on a malicious file with a malformed dimg reference SIGSEGVs. The dereferenced address is 0x0 plus a small constant vtable offset - deterministic across runs and platforms, not attacker-controllable.
• F2 - DoS plus a heap OOB read primitive. The 4 bytes read at the attacker-influenced offset are consumed as a heif_item_id lookup key in HeifContext::get_image(). By itself this is not a trivially-leaking primitive into an external observer; in a larger gadget chain (combined with an info-leak side channel via caching behaviour or timing) it could matter. Exploitability beyond the sanitizer report was not pursued.
• Memory write. Neither bug provides a write primitive.
• Sandbox guidance. Out-of-process decode workers are the right mitigation for downstream consumers that cannot immediately update to 1.22.0. Both bugs result in SIGSEGV in release builds, which a try/catch in the consumer process will not catch.

1. Asserts are not bounds checks. Anywhere a parsed-from-the-file integer is used as an array index or a pointer offset, the check must be a runtime if that returns an error in release builds. assert() is documentation, not protection. F2 looked like a robustness signal in the debug build and a memory-safety report in the release build - same source, same input, same line, different categorisation. Build and fuzz the release-mode ASAN configuration explicitly.
2. Cross-references between two parsed sources are bug factories. The grid header says "R×C tiles." A separate parsed list says "and here are the N tile item ids." A separate part of the file says "and the image is rotated 270 degrees." The decode path has to reconcile all three with the caller's coordinates - which themselves arrive through a public API. F2 is exactly the pattern of one parsed value flowing into arithmetic against a different parsed value. Whenever a header declares a count or a shape and a separate parsed list provides the elements, validate at parse time that the two agree and re-check at use time.
3. Trust boundaries include caller-supplied API arguments. heif_image_handle_decode_image_tile(handle, tile_x, tile_y) is a public API. The coordinates come from the consumer, not the file - but consumers typically derive them from parsed-from-the-file dimensions returned by get_image_tiling(). Either way, libheif has to validate them itself against the displayed grid before they enter inverse-rotation arithmetic. The source-side fix (commit e523ec0b) closes exactly this gap.
4. Sibling-class audit before reporting. The most effective sentence in a security report is "you already do this everywhere else, except here." For F1, the four sibling derived-image classes (overlay.cc, two sites in iden.cc) already do the missing null-check. That makes the fix a five-line patch with a structural precedent rather than a debate about whether the input was valid in the first place. The audit takes ten minutes; it saves the maintainer hours and the reporter a round-trip.
5. Structurally-aware seeds beat random mutation on framed formats. ISO BMFF box framing eats random byte mutations alive - most mutants produce invalid lengths and stop parsing before reaching anything interesting. A 25-seed generator that produces deliberately-invalid-but-parseable HEIFs (grids pointing at missing items, grids pointing at non-image items, size mismatches, irot+imir combinations, extreme dimensions) hit F1's exact 303-byte shape within thirty seconds. The bug class wants a structurally valid container with an inconsistent cross-reference - that is exactly what targeted seeds produce.

The work that produced this disclosure was not one agent grinding through libheif alone. It was a deliberate two-model loop with a human in the conductor seat: one model for execution, one for critique, the human choosing what to commit to.

The execution model (Claude) did the work that takes wall-clock time. Reading the libheif source top-down. Drafting the attack-surface note. Writing the five harnesses. Building the debug and release-NDEBUG libraries. Running the sanity fuzzes. Triaging the two grid signatures. Composing the sibling-class audit table. Minimising F1 to 303 bytes. Authoring the suggested-fix diffs. Drafting the private security report. End to end.

The critic model (ChatGPT) was kept off the execution path on purpose - its job was to challenge conclusions, not author them. The most useful intervention in this campaign was the moment the execution side declared libheif "saturated" after a clean overnight run. The critic pushed back: structured harness fuzzing is complete, but you have not tested chaotic cross-object composition - semi-valid containers with conflicting item references, derived-image-of-derived-image, transforms stacked on the wrong items, iloc extents pointing into parseable-but-weird regions. It produced a full Phase 7 plan with an explicit stopping criterion. The execution side built it: 612 chaos seeds plus 50 size-stress seeds plus 200 box-level mutations, run as smoke, short, and overnight tracks. The result was zero new crashes across 30.4 million executions - but with measurable coverage gain over the prior best, decode_grid_overlay edges climbing from 25,807 to 28,884 (+11.9%) and decode_primary from 25,399 to 27,289 (+7.4%). A strong negative result. Without the critic, that phase would have been rationalised away as diminishing returns and the saturation claim would have rested on absence of evidence rather than evidence of absence.

The same loop ran during disclosure. The first email to the maintainer was drafted by the execution side; the critic edited it for tone (less apologetic, more practical) and recommended the shorter of two phrasings for the CVE-request follow-up. Small edits, real effect on the response.

The human role in the loop is narrower than it sounds and harder than it looks: pick the target, accept or reject the critic's pushback, commit to the actions the execution side proposes, decide when to disclose and how. The models are fast; the judgment about which question to ask is the part that does not scale yet.

This research was done over a weekend, on my own free time, outside work hours, and not as part of my job.

What collapsed is not the difficulty of finding bugs. It is the cost of acting on intent. Each step of vulnerability research - reading code top-down, hypothesising where a bug class lives, building a harness, triaging a crash, doing a sibling-class audit, drafting a clean report with a suggested fix - used to be a manual sequence punctuated by hours of human attention. Now most of those steps are reasoning-over-actions that an agent can execute in seconds against a fully-grounded view of the codebase. The intent here was mine; the wall-clock cost was a fraction of what the same intent used to cost.

The uncomfortable corollary is that today's models are the worst versions of these models we will ever use again. Whatever the bottleneck looks like at this point in 2026, it will be smaller next quarter and smaller still the quarter after. For maintainers, that means the bar for "we would have caught this in code review" is rising faster than the codebase. For defenders, it means the inventory of latent bugs in mature libraries is going to be drained faster than the disclosure infrastructure was designed to handle. For researchers, the leverage now sits less in the act of finding a bug and more in the choice of where to point. The disclosure cadence libheif demonstrated here - 17 days from private report to fixed release, with the maintainer himself authoring the structurally correct F2 source-side fix - is the kind of pace the rest of the ecosystem should be optimising toward.

The bugs are arithmetic mistakes. The story is the timeline.

libheif is the canonical open-source HEIF/HEIC/AVIF container library. Direct downstream consumers include ImageMagick, libvips, GIMP, KDE's KImageFormats, GNOME's image viewers and thumbnailers, and a long tail of Linux desktop image apps. The ecosystem reach is large; the realistic exposure to these specific bugs is narrower, because four gates must all be true: (1) the consumer links a libheif at or before 1.21.2 with the grid-decode path enabled; (2) it actually calls a decode API on user-supplied input; (3) for F2, the input can carry an irot property and a non-square grid; (4) the host has not already received a libheif update through its distribution. Most distributions track libheif closely, so the practical exposure window is the time between v1.22.0 reaching their mirrors and downstream consumers picking up the rebuilt package.

Realistic exposure

This does not mean every browser or every phone is affected. Many mainstream browsers and mobile platforms use different AVIF/HEIF decode paths or platform media frameworks rather than libheif. The realistic exposure is Linux desktop software (image viewers, thumbnailers, file managers), server-side image pipelines and media-processing tools that link libheif, and distributions that package libheif directly. F2's heap OOB read primitive in release-style builds is structurally significant under standard exploit assumptions but does not by itself prove exploitation against any deployed application.

Packaging status as of 2026-05-21

The patch shipped two days ago. The table below is a static snapshot of Repology captured on the day of publication, frozen so it remains a faithful record of where the ecosystem stood when this advisory went out. Sage cells are patched (libheif 1.22.0); red cells are still vulnerable. Of 113 tracked distributions and repositories, 16 had picked up 1.22.0; 97 were still on a vulnerable version. The full list is shown below for record-keeping; the headline numbers above are the takeaway, and a future revision of this page may collapse the full list behind a "show all distributions" toggle.

The vast majority of tracked distributions and repositories in this snapshot still packaged a libheif version that contained both bugs. The patch is local to two functions and small enough to backport, but for most users the realistic path is to wait for the distribution update.

What to do

• Update to libheif 1.22.0. The three fix commits are local to two functions and small enough to backport.
• If you ship a static build of libheif, rebuild against 1.22.0 and re-link consumers.
• For service operators: a libheif decode worker that crashes mid-request should restart cleanly, not poison a longer-lived shared process. Out-of-process decode is the right boundary regardless of this specific bug.