Researchers discover a new way to steal secrets from Android  apps.

If At First You Don’t Succeed

What’s the craic? Thomas Claburn breaks the story: Android ‘Pixnapping’ attack can capture app data like 2FA codes

“CVE-2025-48561”
Security researchers have resurrected a 12-year-old data-stealing attack on web browsers to pilfer sensitive info from Android devices. … Conceptually, it’s the equivalent of a malicious Android app being able to screenshot other apps or websites.
…
The attack works by accessing information about screen display pixels through a hardware side channel, … using a technique inspired by security researcher Paul Stone in 2013. … The researchers have demonstrated Pixnapping on five devices running Android versions 13 to 16: … Google Pixel 6, Google Pixel 7, Google Pixel 8, Google Pixel 9, and Samsung Galaxy S25. … A malicious Android app implementing Pixnapping would not require any special permissions.
…
Google [said], “We issued a patch for CVE-2025-48561 in the September Android security bulletin, which partially mitigates this behavior. We are issuing an additional patch for this vulnerability in the December Android security bulletin. We have not seen any evidence of in-the-wild exploitation.”

And Dan Goodin exercises some critical thinking: Hackers can steal 2FA codes and private messages from Android phones

“Useful research”
The amount of time required to perform the attack depends on several variables, including how many coordinates need to be measured. In some cases, there’s no hard deadline for obtaining the information the attacker wants to steal. In other cases—such as stealing a 2FA code—every second counts.
…
Pixnapping is useful research in that it demonstrates the limitations of Google’s security and privacy assurances that one installed app can’t access data belonging to another app. The challenges, … however, are likely to be significant. In an age when teenagers can steal secrets from Fortune 500 companies simply by asking nicely, … complicated and limited attacks [are] probably of less value.

Horse’s mouth? Alan Wang, Pranav Gopalkrishnan, Yingchen Wang, Christopher Fletcher, Hovav Shacham, David Kohlbrenner and Riccardo Paccagnella defend their work: Pixnapping Attack

“Malicious app”
Stone’s story of knocking iframes and SVG filters together to steal pixels hasn’t really changed with a decade of attacks. … We have demonstrated Pixnapping attacks on Google and Samsung phones and end-to-end recovery of sensitive data from websites including Gmail and Google Accounts and apps including Signal, Google Authenticator, Venmo, and Google Maps. Notably, our attack against Google Authenticator allows any malicious app to steal 2FA codes in under 30 seconds while hiding the attack from the user.
…
Anything that is visible when the target app is opened can be stolen by the malicious app using Pixnapping. Chat messages, 2FA codes, email messages, etc. are all vulnerable. The three steps a malicious app can use to mount a Pixnapping attack are:
1. Invoking a target app … to cause sensitive information to be submitted for rendering. …
2. Inducing graphical operations on individual sensitive pixels rendered by the target app. …
3. Using a side channel … to steal the pixels operated on during Step 2. …
Steps 2 and 3 are repeated for as many pixels as needed to run OCR over the recovered pixels and recover the original content.
…
This work was funded by ARL, … NSF, … Google, Intel, Mozilla, and Qualcomm. … We have open sourced all of this paper’s artifacts at https://github.com/TAC-UCB/pixnapping.

The preprint paper is worth a read for the incredible detail alone. lll-o-lll calls it “clever and evil”:

This is a really interesting new side channel attack — one I had never considered before. It’s like Rowhammer, but for the screen. Clever. Also evil.

How can it be prevented? Aside from throttling per-pixel operations, which seems to be Google’s first, failed attempt, that is. ledow has another idea:

Surely that’s a function that you just lob at the renderer and it does it when it feels like it? It doesn’t have to be performed inline. … The fix for the API would appear to be simple: Do checks on the bounds, etc. as normal, return success immediately, then blit/render/etc. in the background as necessary. The app won’t then have a clue how long a pixel takes to render.

But surely, because it needs a malicious app installed, this isn’t really a huge problem? u/Expensive_Finger_973 agrees:

And if this is ever seen in the wild, the app used to trick people would be something common sense should tell you is either trash that doesn’t work or something malicious. These kinds of stories always remind me of the people you used to see installing custom mouse cursors … or that stupid one where a snow globe was permanently in the bottom right of the screen … and they always complained to no end about how slow their machine was. No **** it is slow Fred — Jesus is currently using all of your RAM to preach a sermon in that background process.

However, [email protected] disagrees, seeing an opportunity for a supply chain hack or app takeover attack:

Normally I would agree, … but in this case the “malicious app” … requires no permissions to do the malicious behavior, which means that the relevant code could be included in any app and wouldn’t trigger a user approval, a permissions request or a security alert. This could be hiding in anything that you install.

Come again? QuattroV explains:

Take a step back and consider a supply-chain attack: Haxxor infiltrates a known-good app, injects the bad stuff, and lets it marinate. Whole-app hijacking too drastic an example? Could maybe happen via libraries, plugins, whatever live third-party asset..

The “graphical operation” the researchers showed was a blur. Which irritates the heck out of that one in the corner:

Android allows you to render your UI to have as its background a blurred view of whatever is being displayed underneath your window. The clever bit then being to extract data from the actual process involved in that blurring. In other words, a horrid and tacky bit of UI “functionality” has been weaponised … (I mean, come on, it was tacky and useless when Windows Aero did it).
…
And as a mere end-user I can’t protect myself by telling the OS to just not support this ghastliness. Yay, I’m being put at risk because UI designers … decided that a cluttered display, with decreased contrast, is so damn clever and important that it went into the OS.

Meanwhile, askariwa gets set to set a setting in the Settings: [You’re fired—Ed.]

Just use the Google Authenticator’s “Privacy Screen” which requires a PIN, pattern, or biometric verification to open the app.

And Finally:

Best of 2019

This month, we’re reprising the best of And Finally (because reasons).

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to  @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Rami Al-zayat (via Unsplash; leveled and cropped)