Security researchers have resurrected a 12-year-old data-stealing attack on web browsers to pilfer sensitive info from Android devices.
The attack, dubbed Pixnapping, has yet to be mitigated. Conceptually, it’s the equivalent of a malicious Android app being able to screenshot other apps or websites.
It allows a malicious Android application to access and leak information displayed in other Android apps or on websites. It can, for example, steal data displayed in apps like Google Maps, Signal, and Venmo, as well as from websites like Gmail (mail.google.com). It can even steal 2FA codes from Google Authenticator.
The attack works by accessing information about screen display pixels through a hardware side channel (GPU.zip), using a technique [PDF] inspired by security researcher Paul Stone in 2013.
Stone’s work described how SVG filters could be used in a timing attack [PDF] to read the pixel values from a web page in a cross-origin iframe, a method subsequently mitigated by iframe and cross-origin cookie restrictions.
The new version of the attack, dubbed Pixnapping, was developed by Alan Wang (University of California, Berkeley), Pranav Gopalkrishnan (University of Washington), Yingchen Wang (University of California, Berkeley), Christopher Fletcher (University of California, Berkeley), Hovav Shacham (University of California, San Diego), David Kohlbrenner (University of Washington), and Riccardo Paccagnella (Carnegie Mellon University).
“Our group’s prior work on GPU.zip (which we presented at S&P 2024) gave us a side channel to leak rendering data, including via Stone-style attacks,” said Alan Wang, a PhD candidate at UC Berkeley, in an email to The Register. “Based on our experience with GPU.zip and after learning about Android’s Custom Tabs API (from Tabbed Out, which was also presented at S&P 2024), we realized we might be able to revive the browser attacks, which then led to the app attacks.”
Wang and his colleagues explain their approach in a paper [PDF] titled “Pixnapping: Bringing Pixel Stealing out of the Stone Age,” scheduled to appear this week at the 32nd ACM Conference on Computer and Communications Security in Taipei, Taiwan.
The attack framework allows a malicious Android app to push pixels into the rendering pipeline using Android Intents – an intra-app messaging mechanism – and then compute on those pixels by overlaying a stack of semi-transparent Android Activities – interface panes or screens – in order to read them. It relies on the Android window blur API to run graphical operations on pixels and uses VSync callbacks to measure rendering time.
The underlying vulnerability is tracked as CVE-2025-48561.
“First, the malicious app opens the target app (e.g., Google Authenticator), submitting its pixels for rendering,” explained Wang.
“Second, the malicious app picks the coordinates of a target pixel whose color it wants to steal. Suppose for example it wants to steal a pixel that is part of the screen region where a 2FA character is known to be rendered by Google Authenticator, and that this pixel is either white (if nothing was rendered there) or non-white (if part of a 2FA digit was rendered there).
“Third, the malicious app causes some graphical operations whose rendering time is long if the target pixel is non-white and short if it is white. The malicious app does this by opening some malicious activities (i.e., windows) in front of the target app.
“Finally, the malicious app measures the rendering time per frame of the above graphical operations to determine whether the target pixel was white or non-white. These last few steps are repeated for as many pixels as needed to run OCR over the recovered pixels and guess the original content.”
The researchers have demonstrated Pixnapping on five devices running Android versions 13 to 16 (up until build id BP3A.250905.014): Google Pixel 6, Google Pixel 7, Google Pixel 8, Google Pixel 9, and Samsung Galaxy S25. Android 16 is the latest operating system version.
Other Android devices have not been tested, but the mechanism that allows the attack to work is typically available. A malicious Android app implementing Pixnapping would not require any special permissions in its manifest file, the authors say.
The attack works on Pixel devices, the authors say, due to the way the Mali GPU implements data compression – lossless compression schemes result in data-dependent compression ratios, which translate to data-dependent rendering times due to memory bandwidth limitations. Those rendering times can be monitored to infer pixel values, allowing displayed text or graphics to be inferred.
As for Samsung devices, the authors say they’re not yet sure whether they can attribute observed timing differences to GPU data compression.
Pixnapping has some limitations. For example, it only leaks 0.6 to 2.1 pixels per second, though the authors say that’s sufficient to recover Google Authenticator codes.
A Google spokesperson told The Register, “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.”
We’re told that Google’s detection mechanisms on Google Play have not found any malicious apps that exploit this vulnerability.
The researchers say that Google has tried to patch Pixnapping by limiting the number of blur API calls that an Android Activity is allowed to invoke. They note, however, that they discovered a workaround, presently still under embargo. The paper suggests that limiting an attacker’s ability to compute on victim pixels would be the most effective means of mitigation, since new side channels are often discovered and Android isn’t likely to get rid of activity layering.
“Google is still working on complete fixes, and we don’t know the status of those currently,” said Wang.
As for the GPU.zip side channel used by the Pixnapping framework, no vendors have announced plans to address it.
The researchers also found that an attacker can send a combination of Android Intent messages to determine all the apps installed on a given device, something that has been disallowed since Android 11 for privacy reasons. Google, they claim, won’t fix this specific bug because it’s not feasible. ®
First Appeared on
Source link
