A Localhost Loophole Broke the Privacy Wall Between Web and Native Apps
Deleting cookies is supposed to end a relationship. Opening an Incognito window is supposed to start a cleaner one. But an award-winning security paper shows how an app already installed on a phone could help a website recognize the same person again—without asking the browser for its stored identity.
The bridge was localhost: the network address a device uses to talk to itself. Web scripts associated with Meta Pixel and Yandex Metrica connected to native Android apps listening on local ports, allowing browser identifiers to be linked with longer-lived app or device identities. The result crossed a boundary that users, developers and even browser threat models largely treated as solid.
There is an important timeline distinction. The researchers disclosed the activity in 2025, and the observed Meta and Yandex methods stopped on June 3, 2025. The fresh development is the publication of the complete study at the August 12–14 USENIX Security 2026 symposium, where it received a Distinguished Paper Award. The paper turns an earlier disclosure into a systematic account of what happened, how widely the browser-side behavior appeared, how vendors responded and where defenses may still have blind spots.
How a website reached an app without leaving the phone
Browsers isolate websites by origin. Mobile operating systems isolate installed apps in separate sandboxes. Those protections are foundational to the promise that one context cannot quietly read another context’s data.
Networking created an unexpected route around that separation. A native app can open a service on the device’s loopback interface. JavaScript running on a public website can then attempt to connect to that service through HTTP, WebSocket or WebRTC. No traffic needs to travel to another machine for the initial handoff: the browser and app meet through the device’s internal network path.
The researchers combined crawls of popular websites with static and dynamic analysis of Android apps. Their website dataset used the top 100,000 sites in a February 2025 Chrome User Experience Report ranking, while their app corpus covered 5,000 Google Play apps. Instrumented Android devices helped the team observe socket activity and match browser-generated localhost traffic with behavior inside installed apps.
In April 2025 mobile crawls, the team recorded localhost WebRTC connections on 15,819 sites from its EU vantage point and 17,368 from the US. Meta accounted for more than 99% of those observed cases. The researchers also found HTTP-based localhost communication on 1,327 EU and 1,379 US sites, with Yandex responsible for about 95%.
Those figures describe sites where the scripts initiated localhost communication. They do not mean every visitor was successfully identified: completing the bridge required the corresponding native app to be installed and available. That distinction matters, but it does not shrink the architectural problem. A third-party script could probe for an app and pass it a browser identifier without a normal cross-app permission flow.
A focused crawl also found that the localhost communication frequently began before users interacted with a consent banner. In the researchers’ measurements, this happened on roughly three quarters of tested Meta sites and more than four fifths of tested Yandex sites. The paper’s legal analysis argues that the lack of transparency and prior consent created serious conflicts with European privacy rules.
Why this is a web app story
This was not a vulnerability limited to PWAs, and the apps observed listening on the other side were native Android apps. That is precisely why installable-web teams should care. A web app runs within browser and operating-system trust boundaries even when it has an icon, a standalone window and an app-like launch experience. Installability does not create a new security perimeter around the code.
Modern products also rarely live in one channel. A company may operate a website, an installed PWA, native companion apps, WebViews, analytics tags and authentication flows at the same time. Evaluating each component separately can miss behavior that only becomes visible when two surfaces coordinate.
The paper reports that all five Android browsers tested in its 2025 snapshot—Chrome, Edge, Firefox, DuckDuckGo and Brave—were at least partially affected by the reproduced techniques. The researchers also demonstrated that a browser could reach a local server app on iOS, although the campaigns observed in the wild were focused on Android and practical iOS exploitation would face additional background-execution constraints.
The broader lesson is uncomfortable but useful: browser privacy controls protect browser state. They cannot keep their promise if another installed process can silently receive an identifier and reconnect it to a durable identity.
The campaigns stopped, but the trust question remains
Meta and Yandex terminated the observed methods on the day of the researchers’ public disclosure in June 2025. Browser vendors also deployed mitigations. Chrome restricted the ports used by the two implementations, DuckDuckGo updated its tracker blocklist, and browser teams continued developing Local Network Access protections that place localhost or local-network requests behind permission checks.
Those responses reduced the immediate risk, but the paper explains why actor-specific blocking is not a complete answer. Port restrictions stop known implementations. Domain blocklists stop known scripts. Neither necessarily removes the underlying communication channel.
The researchers developed additional proof-of-concept paths involving global-unicast IPv6 addresses in WebRTC and multicast DNS lookups on local domains. They describe these alternatives as technically exploitable, but did not observe them being abused in their web crawls. They disclosed the new vectors to browser makers before submitting the paper.
That caveat is essential. This is not evidence that a replacement campaign is operating today. It is evidence that localhost and the local network need a clearer, more consistent place in browser and mobile threat models.
What product and engineering teams should do
- Map the web and app surfaces together. Inventory browser scripts, native SDKs, WebViews, companion apps and local services as one system. Cross-context behavior will not appear in a web-only vendor review.
- Test with relevant apps installed. Reproduce mobile journeys before and after consent, in private browsing, and after clearing site data. Monitor HTTP, WebSocket, WebRTC and operating-system socket activity rather than assuming one network panel captures every path.
- Minimize legitimate localhost exposure. If a product genuinely needs a local service for authentication, hardware access or a companion workflow, require an explicit user action, authenticate messages and reject unsolicited requests.
- Prepare for permission friction. Local Network Access protections can turn an invisible connection into a user decision. Products that depend on the capability need a clear explanation and a graceful fallback when access is denied.
- Make consent sequencing enforceable. Do not merely configure a banner. Verify that third-party scripts capable of identity or network activity cannot run before the user’s choice is recorded.
Worauf IndApp als Nächstes achtet
The next milestone is not another blocklist entry. It is consistent protection across HTTP, WebSocket, WebRTC and newer transports, with browser behavior that users can understand and developers can test. Loopback access may also need to be separated more clearly from access to printers, routers and other devices on a local network; combining them under one vague prompt risks both confusion and consent fatigue.
We are also watching developer tooling and app review. The paper notes that the WebRTC route was not visible in Chrome’s standard Network panel during the tested period. If cross-context traffic is difficult for developers to see, audits will miss it. And if an app store reviews native code without considering its coordinated web scripts, distribution safeguards can miss the real product behavior.
Installable web apps compete partly on trust: transparent delivery, inspectable code paths and user-controlled permissions. The localhost episode is a reminder that trust cannot stop at the edge of the browser window. The app already on the phone may be part of the web security model, whether the product team planned for it or not.
Weiterführende Informationen
Aktuelle Nachrichten
