CVE-2026-58868: crafted HEIF grid images cause out-of-bounds writes in Android mediaserver

A researcher who found the bug through static analysis of Android's media stack has published a detailed write-up on dev.to of CVE-2026-58868, a memory-corruption flaw in the HEIF image-decoding path. According to the post, Google's Android security bulletin classifies the issue as a critical remote code execution vulnerability affecting Android 14, 15, 16, 16 QPR2 and 17 — though the researcher also reproduced it on an Android 12 device, suggesting the affected range may be wider than the bulletin implies.

How the flaw arises

HEIF files can describe a single large picture as a grid of smaller encoded tiles. As the researcher explains, Android allocates the output buffer using the image's declared overall dimensions, while each tile's position is computed from the tile's own decoded size. In the proof of concept, tiles decode at 1024 by 1024 pixels inside an output image whose declared dimensions cannot accommodate that layout.

Tile measurements enter the pipeline early: StagefrightMetadataRetriever reads the tile width and height from the file and uses them when configuring a decoder for images that lack an embedded thumbnail. The decisive defect sits in MediaImageDecoder::onOutputReceived(), which clips a tile's right and bottom edges to the canvas but never rejects a tile whose starting position already lies outside the image. A tile that begins below the canvas can therefore end up with a negative crop height.

From bad crop to bad write

The next layer fails to catch the anomaly. ColorConverter compares the source and destination crop rectangles for equality; the researcher notes that both can be invalid in exactly the same way and still pass, and that the remaining stride and alignment checks never establish that either rectangle lies within its buffer.

The crop dimensions then reach libyuv, which accepts height as a signed integer. Inside NV21ToARGBMatrix, a negative height is read as a request to flip the output vertically, so libyuv moves the destination pointer before converting pixels. The crash data is consistent with a height of -1096 arriving at that call — at which point a missing validation check has become a write outside the output image.

The crash and the attack path

The captured crash comes from Gmail on the researcher's OnePlus handset: a SIGSEGV in the 32-bit ARM mediaserver process, in a thread named ImageDecoderOut, with the stack running through libyuv's NEON conversion routines and up into MediaImageDecoder. At the faulting instruction, a vector store tries to write a 32-byte block of converted pixels to an unmapped address, and two registers still hold 0x400 — decimal 1024, the attacker-chosen tile dimension.

What makes the bug notable is how little interaction it demands. Opening a message in Gmail was enough: thumbnail generation decoded the hostile image without any tap on the attachment or a manual download. The researcher reproduced the same behaviour through Google Files and Google Photos.

Disclosure status

The proof of concept is being withheld. The CVE was published only days before the write-up appeared and several Android versions had not yet received a fix, so the researcher declined to release the exploit or further implementation details. The analysis also frames the issue not as broken logic but as absent validation: every component behaved as written, and nothing ever checked that a tile's origin fell inside the destination image.

Why it matters

Media parsing remains one of the most productive zero-click attack surfaces on mobile devices, and this flaw shows why: images are decoded automatically, inside system processes, before a user has made any decision about them. A malicious picture that arrives by email or chat only needs to be rendered as a preview. Google's critical rating signals that an attacker-influenced out-of-bounds write in mediaserver is more than a crash risk, even though the public write-up demonstrates only the crash. For Android fleet operators, the practical steps are to apply the current security update promptly and to treat the bulletin's version list with caution given the Android 12 reproduction. For developers, the write-up is a compact case study in how a single unchecked assumption — that a tile's starting offset is valid — can travel untouched through several layers of checks that each verify something else.