Android Pixnapping Exploit Grabs Onscreen 2FA Codes

A newly revealed attack called Pixnapping can steal whatever is on your Android screen—including one-time two-factor authentication (2FA) codes, it turns out—without tripping the usual permission checks. The research team that uncovered the technique says a malicious app could be used to reconstruct on-screen images in near real time, so that an attacker could easily monitor what someone was doing and seeing inside apps like Google Authenticator, Gmail, Signal, Venmo and even some types of phone-based two-factor authentication codes.

What Pixnapping Is and Why It Matters for Android Security

Pixnapping is outlined in a document “Pixnapping: Bringing Pixel Stealing out of the Stone Age” by academics at the University of California (Berkeley and San Diego), the University of Washington, and Carnegie Mellon University. The vulnerability is identified as CVE-2025-48561. Unlike older malware that relies on screen recording or AccessibilityService-based permissions, Pixnapping uses appropriate Android graphics capabilities and a hardware side-channel to figure out the value of pixels an app is drawing—even when those apps try to prevent screenshots.

The bottom line: any sensitive information that briefly flashes up on screen is fair game. That counts six-digit TOTP codes, one-time SMS codes, email previews, and last but not least, chat content. 2FA codes had been “successfully” stolen on Google Pixel devices during the 30 seconds they were active, without alerting users to their thefts, researchers said.

How the Pixnapping Attack Works on Android Devices

Pixnapping consists of three synchronized steps. First, a zero-permission, risky app programmatically leads the target app to display sensitive content and propagates that through Android’s composition pipeline. That’s not a screenshot; that’s how the rendering is.

Second, as an attacker app, it applies a semi-transparent overlay with controlled blur effects on certain screen portions—e.g., the region where Authenticator displays its digits. “Disguising and increasing the size of those areas does nothing to reduce the amount of information that’s there, but it makes lots of very subtle differences between all these pixels much greater.”

Third, Pixnapping utilizes a side-channel attack on GPU compression called GPU.zip. Since images tend to compress differently under a graphics compression format based on the data lying underneath them, an attacker who keeps invoking and measuring these operations can deduce exactly which pixels lie under the overlay. By overlaying this on multiple frames, an attacker could reconstruct the contents of the screen, one pixel at a time, and effectively produce a ‘screenshot’ the OS cannot see or block with normal flags like FLAG_SECURE.

Devices and Android Versions Impacted by Pixnapping

The team confirmed attacks worked on five devices running Android 13 to 16: Google Pixel 6, Pixel 7, Pixel 8, and Pixel 9, as well as the Samsung Galaxy S25. Researchers claim they are able to consistently retrieve full 2FA codes which have been entered in the time domain using the Pixel hardware. Results on the Galaxy S25 were even noisier, but reliability wasn’t zeroed out. The authors note that the mechanisms Pixnapping employs are standard across Android devices, indicating there’s likely additional exposure beyond what was demonstrated in their test set.

In controlled demos, the researchers claim to have retrieved sensitive data from Google Accounts pages in Chrome (even when they were redacted), the content of email subject lines in Gmail, message previews in Signal and payment information stored by gun-selling websites. Next we’ll see how this is illustrated in practice, but it’s worth noting that by exposing those secrets on the screen even for an instant, any app can be a target.

Patches and Mitigations Underway to Limit Pixnapping

Google has released a preliminary fix that rate-limits how frequently an app is able to call blur operations, thus curtailing one critical element in the chain. It is still possible to bypass it, the researchers said, and a workaround has already been reported privately. One further, more general fix, which avoids lock-screen bypass and is also bigger and more comprehensive, will be issued in a future Android security bulletin. So far, Google has told independent media there is no evidence of active exploitation in the wild.

For platform engineers, the problem is architectural: the graphics stack optimizes for performance and visual effects across apps, which ends up opening side channels. The restrictions to prevent cross-app pixel inference are likely to involve compositing effects being more strongly isolated and overlays better controlled, and serve as a hardening surface against GPU compression leakages.

What You Can Do to Reduce the Risk Right Now

• Opt for phishing-resistant 2FA: use passkeys or FIDO2 security keys where available. The ones that don’t show secrets on screen eliminate the need for Pixnapping the target.
• If you have to use TOTP apps, show codes only when needed and close the app as soon as possible. Don’t switch back and forth quickly between code and sign-in on the same device.
• Download apps from trusted sources and examine unknown utilities that create overlays, pop-ups, or visual effects. If you don’t recognize an app, remove it. Turn on Google Play Protect and make sure firmware and Play system updates are up-to-date.
• If available, opt for app prompts or number-matching push approvals instead of entering codes; bypass SMS codes, which have their own interception risks.

The Bigger Security Lesson for Android and 2FA Users

Pixnapping is a reminder that “no permission required” does not mean “no risk.” Contemporary mobile platforms are stacked systems, with harmless features—overlays, blur effects, GPU compression—that can interplay in unexpected ways. The best defense for users and IT teams is to limit on-screen secrets by using passkeys and hardware-backed authentication when available.

The road forward for the Android ecosystem is relatively straightforward but not easy: limiting cross-app graphical effects, patching compression side channels and establishing that privacy-preserving defaults should be just that. Until those changes come through across the board, it’s safe to treat on-screen codes like you would exposed data.