2026-08-24

The part you cropped out of a screenshot can still be in the file: what the aCropalypse bug showed

Almost everything this blog covers is metadata in the strict sense: named fields, written on purpose, sitting in a place a parser knows to look — EXIF GPS coordinates, a docx's author property, a PDF's Producer string. The aCropalypse bug, disclosed in March 2023, was a reminder that files can carry a second kind of hidden payload that has no field name at all: leftover data from an earlier version of the file, sitting past the point where every normal viewer stops reading. In this case, the leftover data was the exact thing the person had tried to remove — the cropped-out part of a screenshot. The bug itself was patched three years ago. The files it produced are still sitting in chat histories and photo libraries, which is why the story is still worth knowing.

A crop that didn't actually remove anything

The bug lived in Markup, the built-in screenshot editor on Google Pixel phones, and it was found in early 2023 by security researchers Simon Aarons and David Buchanan — Aarons got suspicious because simple cropped screenshots had abnormally large file sizes. Buchanan's technical write-up pins down the cause: when Markup saved a cropped screenshot over the original file, the file was opened without the flag that truncates it, so, in his words, "when the cropped image is written, the original image is not truncated." A crop makes a PNG smaller, so the new file only overwrote the beginning of the old one — and everything of the original past that point stayed on disk, dangling after the new image's official end. The result was a file that opened everywhere as the innocent cropped version while physically containing most of the uncropped original. The failure traces to an undocumented behavior change in Android 10, released September 2019: a file-mode string that used to mean "write and truncate" quietly stopped truncating, and Markup's code was never updated to match. Google was told in January 2023 and had a fix finalized internally by January 24, but it only reached Pixel phones with the March 13, 2023 security patch — which left roughly a three-and-a-half-year window of affected crops. The vulnerability is CVE-2023-21036.

How bad "leftover bytes" gets in practice

Trailing garbage after a PNG's end might sound harmless — it's a truncated tail of a compressed stream, missing its beginning. It wasn't harmless. PNG's compression (zlib) restates its decoding tables at intervals, so Buchanan wrote a recovery tool that scans the leftover bytes for the next intact block boundary and decompresses everything from there, reconstructing the bottom portion of the original image. His own demonstration is the memorable part: he took a screenshot of an eBay order confirmation, cropped it down to just the product image, and then recovered his own full postal address from the "cropped-out" remainder of the file. That is precisely the shape of the worst case: the region someone deliberately cut out — the address, the account number, the rest of the conversation — is exactly what the leftover data preserves.

Windows had the same bug

Within days of the Pixel disclosure, researchers found the identical failure in Microsoft's screenshot editors — Snip & Sketch on Windows 10 and Snipping Tool on Windows 11. Same shape: crop an image, save over the original, and the file keeps the cropped-out data after its official end. Microsoft assigned it CVE-2023-28303 and shipped out-of-band fixes through the Microsoft Store (Snip & Sketch 10.2008.3001.0, Snipping Tool 11.2302.20.0). Microsoft rated the severity Low, reasoning that exploitation requires an uncommon sequence — take a screenshot, save it, crop it, save it again over the same file — but that sequence is not exotic behavior; it's roughly what "let me quickly crop this before sending" looks like when the editor defaults to overwriting.

Why a 2023 patch doesn't clean a 2021 file

Both patches fixed the editors. Neither patch — this is the part coverage at the time kept emphasizing — did anything to the files those editors had already produced. A screenshot cropped on a Pixel in 2021 contains what it contains, wherever it has been copied since. Whether any given shared copy is still recoverable came down to what happened to the file after it left the device: platforms that re-encode uploaded images produce a fresh file and the trailing data is gone, while platforms that stored and served the uploaded bytes as-is preserved it. Discord, which served files unmodified, added its own mitigation on January 17, 2023 — but images uploaded there before that date, like files sitting in any archive or message history, remain whatever they were when they were made.

Where NearScrub happens to reach — and the two honest caveats

NearScrub is a metadata scrubber, and aCropalypse is not metadata, so it's worth being precise about what actually happens. When NearScrub processes a PNG, it doesn't edit the file in place — it walks the chunk list from the signature onward, keeps the chunks that aren't on its removal list, stops at the IEND chunk, and writes a new file containing only the ranges it kept. Anything sitting after IEND is not in any kept range, so it is simply never copied into the output. We verified this directly against scrub-core.js: a PNG with trailing bytes appended after IEND comes out of the scrub at exactly the clean file's size. So a PNG that has been through NearScrub leaves with its text, EXIF, and timestamp chunks removed — and, as a structural side effect, without any aCropalypse-style trailing data either.

Two caveats, both worth stating plainly. First, this is a PNG-only side effect: NearScrub's JPEG path copies everything from the start of the compressed image data to the end of the buffer in one piece, so trailing bytes after a JPEG would survive a scrub. The incidental protection described above is real, but it does not generalize across formats. Second, NearScrub's report screen won't tell you about trailing data. The detection step walks the chunk list — the same walk that stops at IEND — so a cropped screenshot with no text chunks and a megabyte of leftover original image will honestly report "None found." The rewrite still rebuilds the file and still drops the trailing bytes; the report just has no line item for them. A scrubber that listed "leftover data after end of image" as a detected finding would be a reasonable future improvement, but we're not going to claim the current report shows something it doesn't.

What this changes about the habit

The standing advice on this blog is to treat the file that leaves your device as something you process yourself, rather than trusting whatever touched it last — and aCropalypse is that advice's sharpest real-world example, because the thing that betrayed people was the editor they used specifically to remove information. Keep your screenshot tools updated; both editors here have been fixed for years. But for the files that already exist — the cropped screenshot from 2021 still sitting in a chat upload, the "redacted" image in an old folder — the fix is the same one-way door this tool is built around: a rebuild, on your own device, that carries across only what a parser actually read. That rebuild is what a re-encode by a platform does by accident, and what a chunk-walking scrub does by construction. What it is not, ever, is the file the editor happened to save over the original.