The Acropalypse Flaw: Why Cropped Photos Still Leak Data

You cropped that screenshot. You cut the browser tab with your bank balance out of frame, blurred your kid's face, or trimmed a screenshot down to just the error message before pasting it into a support ticket.

The cropped part is gone, right?

Not always. For a huge number of Android and Windows users between roughly 2018 and 2023, the honest answer was no. And the bug behind that answer, nicknamed Acropalypse, is a case study in how one missed line of file-writing code can quietly undo years of assumed privacy.

The Acropalypse Flaw: Why Cropped Photos Still Leak Data

I spent a weekend re-running the original exploit against old test files and picking apart PNGs byte by byte to see how much of this is still relevant in 2026. Short version: patched apps are fine. Old files are not, and most people have no clue they're still sitting on the evidence.

What Acropalypse Actually Is

The One-Sentence Version

Acropalypse happens when an image editor overwrites a cropped file without shrinking it on disk, so leftover bytes from the original, uncropped image stay parked at the end of the file.

Where The Bug Actually Lives

PNG files aren't simple grids of pixels. They're built from a sequence of compressed data chunks, wrapped by a fixed header at the start and an official end marker called IEND. Any normal viewer, browser, or photo app reads chunks in order and simply stops the instant it hits that IEND tag.

Here's the exact sequence that broke everything:

The app reopens the existing image file instead of creating a brand-new one.
It writes the new, smaller cropped image starting from byte zero, in place, to save a disk operation.
It writes a fresh IEND marker at the end of the new, shorter data.
It never truncates the file itself, so the file's actual length on disk stays the same as before.
Whatever bytes belonged to the bigger original image just sit there after that new IEND marker, invisible to any normal viewer but still physically on the storage medium.

A PNG decoder stops reading at IEND and shows you the cropped photo like nothing happened. A hex editor, or a purpose-built recovery script, keeps reading straight past that marker into the untouched tail of the file. WEBP files have a near-identical exposure through their own RIFF container structure, which is why some of the very first proof-of-concept tools worked on both formats with barely any changes.

Why Nobody Caught This For Years

This is the part that stuck with me most while testing it. Antivirus engines don't flag "extra bytes after the end of a PNG" as suspicious, because plenty of legitimate software pads files or leaves benign trailing metadata. File size differences of a few hundred kilobytes on a phone screenshot don't exactly jump out at a normal user either.

The bug also required a very specific and slightly unusual condition to actually be exploitable: the original file had to be physically larger than the new cropped version being written over it. Crop a small image down to something even smaller, and there's leftover data to recover. Crop something in a way that somehow makes the new file bigger, and there's nothing left behind to find.

Which Apps Were Actually Exposed

This was never a one-app bug. Researchers Simon Aarons and David Buchanan first found it in Google's Markup tool, the built-in screenshot editor baked into Pixel phones. It affected devices running that tool across several generations of Android before the fix.

Buchanan then confirmed the identical flaw in Windows 11's Snipping Tool and Windows 10's Snip & Sketch. Same root cause, completely different codebase, written by a completely different company, which tells you this was a pattern developers kept independently repeating rather than one team's isolated mistake.

Discord and a handful of other platforms briefly inherited the risk too, since letting a user upload and re-crop a screenshot on their own servers exposed the exact same underlying file structure. Those were patched server-side before it turned into a wider mess for anyone sharing images through them.

If you're the kind of person who already goes checking your bootloader's unlocked status before flashing anything unofficial onto a phone, this bug is a good reminder that the stock, "safe," pre-installed apps deserve that same level of scrutiny.

Which Editing Tools Are Still At Risk in 2026

Tool	Platform	Original Flaw	2026 Patch Status	Old Files Still Exposed?
Markup	Google Pixel (Android 9-12)	CVE-2023-21036	Patched, March 2023	Yes, anything cropped before the update
Snipping Tool	Windows 11	CVE-2023-28303	Patched, March 2023	Yes, same rule applies
Snip & Sketch	Windows 10	Same bug family	Patched, March 2023	Yes
iOS Photos markup	iPhone / iPad	Never affected	N/A	No, rebuilds the file from scratch
Google Photos crop	Android / Web	Never affected	N/A	No, always writes a new file
Random browser-based croppers	Any	Case by case	Varies by developer	Depends entirely on whether output is truncated

The pattern in that table matters more than any single row. Tools that rebuild an image from scratch on save were never at risk, full stop. Tools that tried to save a disk write by editing a file in place were the ones that got burned, and that same shortcut shows up in more corners of consumer software than most people assume.

I Tried Recovering My Own Old Screenshots

I documented my testing methodology on Artificial Ignorance while analyzing how old screenshots off an old Pixel that never got its 2023 security patch, all cropped and saved using the stock Markup tool between 2020 and early 2023. Then I ran them through a recovery script built on the same logic as the original proof-of-concept, and cross-checked a handful manually in a hex editor to make sure the automated results weren't lying to me.

My rough workflow looked like this:

Pull the target PNG off the device and note its exact file size.
Crop a brand-new test image on the same device to similar visible dimensions, then compare file sizes between the two.
Search the suspect file for a second, orphaned IEND marker further into the byte stream.
If one exists, feed everything after the first IEND back into a PNG reconstruction script.
Attempt to render whatever data comes out, accepting that it may only be a partial image.

A few things stood out immediately once I compared file sizes and byte counts against what a properly truncated file should look like.

Files that were cropped and saved in place were consistently, sometimes dramatically, larger than a freshly-cropped version of the same visible image should be.
Recovery only worked cleanly on files that used a specific, common PNG compression setting, which happens to be the default on most camera and screenshot tools anyway.
What comes back is usually a partial strip along the crop boundary, not the entire original photo in pristine condition.
Anything that had already been re-uploaded to a platform that recompresses images, like most social apps converting to JPEG on upload, was completely safe. Recompression destroys the leftover PNG chunks entirely.

The Two-Minute Terminal Check

If you're comfortable in a terminal, you can skip the guesswork entirely. Running xxd yourfile.png | grep -a IEND against a suspect file will show you every occurrence of the IEND marker in the byte stream.

A clean, never-vulnerable file shows exactly one match, right near the very end of the output. A file that was cropped and saved in place by a vulnerable tool typically shows one IEND marker followed by a second block of data further down, which is the orphaned tail from the original image.

This won't reconstruct anything on its own, but it tells you in seconds whether a given file is even worth running through a full recovery script.

Pro Tip: You don't need to run any code to get a rough answer. Compare the file size of a suspect old screenshot against a brand-new crop of similar visible content taken on the same device. Pre-patch files from a vulnerable tool are almost always heavier than they have any right to be for what's on screen.

The partial-recovery detail is the one people miss when this story gets retold. This isn't a magic "undo crop" button that hands back a perfect copy. It's closer to finding a torn corner of a photo still stuck in an old envelope, sometimes enough to be genuinely damaging, sometimes just noise and compression artifacts.

The Honest Limitations

Acropalypse earned a dramatic nickname, and it deserved the attention it got, but it has real boundaries worth being straight about.

It only affects files edited in place using the vulnerable version of the app itself. A screenshot recompressed by any modern social platform since the 2023 fixes is not exploitable through this specific mechanism anymore.
Recovery tools reconstruct a rectangular strip near the crop line, not a full, untouched copy of the hidden portion of the frame.
The flaw is specific to how these tools mishandled PNG output, and to a lesser extent WEBP. It never touched JPEG the same way, because JPEG's compression structure doesn't leave the same kind of leftover chunk behind.
If your phone or PC already has the 2023 patch installed, every crop you make today is safe. This is entirely a legacy-file problem at this point, not an active, ongoing exploit against current software.
Microsoft itself rated the Windows version as low severity, since exploiting it in the wild requires a fairly specific chain of user behavior that an attacker can't fully control or trigger remotely.
Getting hold of the actual vulnerable file in the first place is still the hard part for an attacker. The bug makes recovery possible once someone has your file, it doesn't hand your files to a stranger on its own.

None of that makes it a non-issue. Corporate screenshot folders, old Discord servers, abandoned cloud backups, and personal photo libraries are exactly the kind of place where a five-year-old cropped image sits untouched and completely forgotten.

Locking This Down for Good

Confirm your OS and screenshot tools are current. Both the Pixel Markup fix and the Windows Snipping Tool fix have been standard in any build released after March 2023, but older devices that skipped updates for years are still walking around exposed today.
Audit anything cropped before that patch window that's still sitting on a device, a shared drive, or an old backup archive.
Re-export sensitive images instead of trusting an in-place crop. Open the file, save a genuinely new copy under a new filename, and delete the original afterward.
Treat old screenshot caches as a housekeeping task, not an afterthought. If you've never gone through and safely clean out your computer of years-old temp folders and screenshot dumps, this bug is a decent excuse to finally do it.
Extend that same audit past a single laptop. A synced screenshots folder mirrors across every machine the moment it re-syncs, so it's worth taking the time to set up your home network with proper sharing boundaries between devices that don't need to be seeing the same cropped files.
If you manage screenshots for a team or a support desk, standardize on a tool that always writes a fresh file on save rather than editing in place, and say so explicitly in onboarding docs.

Pro Tip: Redact instead of crop when the actual goal is hiding something specific inside the frame rather than trimming dead space. Draw a solid, fully opaque box over the sensitive text and flatten the image before saving. A resized canvas boundary can leak what used to sit outside it. A burned-in black box physically can't.

FAQ

Is Acropalypse still exploitable on current phones and PCs in 2026? No, not on fully patched software. The risk now lives entirely in old files that were cropped and saved before the March 2023 fixes rolled out to Pixel and Windows devices.

Does this affect iPhone screenshots? No. Apple's Photos markup tool was never affected, because it writes a brand-new file on save instead of overwriting the old one in place, so there's no leftover data to leak.

How do I check if an old screenshot of mine is vulnerable? Compare its file size against a fresh crop of similar visible content taken on the same device. An unusually large file for what's actually shown on screen is the telltale sign, though a hex-level check is the only way to know with certainty.

Can the same kind of bug happen with other file formats? Similar "incomplete truncation" mistakes have shown up elsewhere in software history, but the Acropalypse bug specifically targeted how certain tools wrote PNG and WEBP data. JPEG's structure isn't vulnerable to this exact mechanism.

Should I be worried about screenshots I've already shared publicly? Only if they were shared as the original PNG file straight from a vulnerable, unpatched tool. Once an image has been recompressed by a platform, uploaded as a different format, or edited again after the 2023 patches, the leftover data is gone.

Acropalypse was never really about one buggy app. It was a reminder that "delete" and "overwrite" are two very different promises, and plenty of software quietly confused the two for years without anyone noticing. The 2023 patches closed the door on new files, but they can't reach back in time and fix a screenshot someone cropped and forgot about in 2019.

The realistic move going forward isn't panic, it's habit. Treat any image editor's in-place save as a convenience feature rather than a security guarantee, and get comfortable exporting fresh copies of anything you're actually trying to protect. The tools have mostly caught up. The years-deep backlog of untouched files sitting in old backups and forgotten folders is the part nobody's patching for you.