Simon Aarons and David Buchanan disclosed on the 17th of March a vulnerability in Google Pixel's Markup tool — the screenshot-cropping-and-annotation feature that ships with Pixel devices — that allows recovery of content cropped out of screenshots that have been processed by the tool (acropalypse.app). The technical mechanism is a bug in the Markup tool's PNG file-writing — the tool overwrites the cropped portion of the image but does not properly truncate the file to the new image's actual byte length, leaving the original (uncropped) image data appended to the file after the new image's IEND chunk. A PNG decoder that ignores additional data after IEND will display the cropped image, but the original uncropped data is recoverable from the file's residual bytes by careful parsing.
The customer-organisation implications are limited but the structural lesson is interesting in two directions. First, the specific vulnerability has implications for any documents — screenshots specifically — that have been processed through the affected tool and shared in contexts where the original cropped content was sensitive. The aggregate customer-organisation-relevant population of such documents is, on plausible estimates, substantial — many years of Pixel users having shared cropped screenshots in chat, email, and social media. The retrospective-data-exposure question is real but operationally unaddressable; the documents that have been shared are out of customer-organisation control.
Second, the structural class of vulnerability — file-format-handling bugs that produce information-disclosure through residual-data persistence — is a category that has been historically less prominent in the public-vulnerability literature than the memory-corruption-and-injection categories. The aCropalypse class of bug applies in principle to any file-format-processing tool that performs operations that should produce truncated output but does not properly truncate. The corresponding bug class in Windows Snipping Tool (CVE-2023-28303) was disclosed shortly after the Pixel case and has comparable shape. The discipline of file-format-truncation-correctness is, on the public record, less well-developed than the memory-safety discipline, and the post-aCropalypse conversation about the broader audit of the file-format-processing tooling across major operating systems and applications is going to be a thread for some time.
For the customer-portfolio briefings, the aCropalypse case has produced a useful conversation about the data-disclosure-via-routine-tooling category of risk. Customer-organisation employees use a wide range of routine document-processing tools (screenshot tools, image-cropping tools, PDF redaction tools, document-format conversion tools) and the assumption that those tools produce safe output has, on the case-record, not always held. The Snipping Tool case in particular has implications for Windows-fleet-using customer organisations.
The patches landed quickly — Google's March Pixel security update addresses the bug, and Microsoft's Patch Tuesday for March addresses the Snipping Tool equivalent. The customer-portfolio patching cycles incorporated both. The aggregate customer-organisation operational cost is moderate; the structural lesson about file-format-tooling audit will inform some of the 2023 customer-organisation programme work.
I will note this for the file. The longer-form analysis of file-format-tooling-audit-as-a-discipline is for a separate piece if the topic continues to develop.