Your iPhone's Tor Browser is leaking your real IP?!

Somewhere on your iPhone right now, there may be a browser you installed specifically because you did not want websites to know who you are. Maybe it routes your traffic through Tor. Maybe it gives every tab its own separate identity. Maybe you're just using Apple's own iCloud Private Relay and trusting the marketing. Whichever it is, you made a deliberate choice to hide your IP address, and you probably assumed the software honored it.

This week, security researchers Talal Haj Bakry and Tommy Mysk published findings that say otherwise. On August 4, they described three separate features in WebKit (the browser engine underneath every browser on iOS) that quietly walk around the proxy your browser configured and reach the internet directly. When they do, the website on the other end learns your real IP address, and in one case your real DNS resolver. Not a masked one. Not a relay's. Yours.

It's a good bug. It's also a better story about power than about code, and we will get to why.

How the leaks work

The three leaks are unrelated features that fail in the same way, which is the detail that makes this interesting rather than just embarrassing.

The first is DNS prefetching. Web pages can include a hint that says, in effect, "the user will probably click a link to this domain soon, so go look up its address now and save a few milliseconds." It's a performance optimization, and a reasonable one. The problem is that WebKit performs those lookups using the system's own network configuration rather than the browser's proxy. So a website can embed a unique, made-up hostname for every visitor, wait for the lookup to arrive, and see exactly which network and which resolver it came from. This one arrived with iOS 26.0 last September.

The second involves WebAuthn, the standard behind passkeys. A relatively new addition lets a site declare that several domains belong to the same organization, so a passkey created on one works on another. To verify that claim, the operating system's credential service fetches a small file from the site. That fetch happens at the OS level, outside the browser, and it has no idea a proxy exists. Worse, when a page uses the "conditional" mediation mode, this happens with no prompt and no visible interface at all. Nothing on screen tells you anything occurred. This has been present since iOS 18.0.

The third is WebTransport, a newer way for pages to open a fast, low-latency connection to a server over QUIC. A single line of JavaScript opens the connection, and WebKit hands it its own default network settings rather than the browser session's proxied ones. This one is the freshest, shipping in iOS 26.4 in March.

Different features, different teams, different years. The same root cause: all three happen outside the normal page-loading path. A browser that configures a proxy for its web content is configuring the road it knows about. These features take side streets.

Who this actually hurts

Here's the part that should bother you. This flaw doesn't harm careless users. It harms careful ones.

If you use a full-device VPN, you're fine. A VPN captures everything leaving the device at the network layer, so even a rogue lookup goes through the tunnel. The people exposed are the ones who chose a browser-level privacy tool. Like Tor browser on iOS, a compartmentalizing browser like Psylo, or iCloud Private Relay. Those tools proxy at the app level, which is precisely the layer these three features skip.

That's an ugly inversion. The user who installed a Tor browser on their phone did so because they wanted more protection than a VPN offers, and in these specific cases they got less. There's a small dark comedy in the one configuration that escaped: Onion Browser's most aggressive setting relies on Lockdown Mode, which switches off WebTransport entirely. Paranoid defaults, accidentally vindicated.

The part you can't fix by switching apps

Normally this is where I'd tell you to use something else. That's the reflex, and usually it works. Don't like how a browser handles your data? Install a different one. The whole culture of digital self-defense rests on the assumption that exit is always available.

On iOS, for the browser engine, it isn't. Apple's App Store rules require every browser on the platform to use WebKit. Chrome on your iPhone is WebKit. Firefox on your iPhone is WebKit. Your Tor browser is WebKit. Brave, Edge, DuckDuckGo, all WebKit. What looks like a shelf of competing products is one engine wearing different jackets.

So when a leak lives in the engine, there is no browser you can install to escape it. The choice that would normally save you was removed as a matter of policy before you ever picked up the device. Every iOS browser developer, including the ones whose entire product is anonymity, is downstream of decisions they cannot override, and they inherit each new networking feature whether it respects their proxy or not.

That's the real lesson. A browser-engine monopoly on a platform converts one team's oversight into a platform-wide deanonymization vector. It's not that WebKit is bad. It's that when a hundred million people's privacy tools all sit on one engine they can't replace, the engine's mistakes become everyone's mistakes simultaneously, and no amount of user diligence routes around it.

What to do this week

Test it. The researchers built a proof-of-concept page that reveals whether your setup leaks, and the whole point of a finding like this is that you don't have to take anyone's word for it. Open it in whatever you use to browse privately and see what comes back.

Then internalize the distinction that this incident makes concrete: a VPN and a proxy browser are not interchangeable. They protect at different layers and they fail in different ways. If your reason for hiding your IP is serious, layering a device-level tunnel underneath your private browser is no longer belt-and-suspenders paranoia. It's the thing that would have covered you here.

Consider Lockdown Mode if your threat model justifies it. And if you use Psylo, update version 1.3.1 blocks prefetch hints and turns off WebTransport and WebAuthn by default, with per-site toggles if you need them back.

That last design choice is worth sitting with. Off by default, on by explicit request. It's slower to use and it breaks a few sites, and it's also the only posture that survives features nobody has invented yet. Privacy configured after the fact is always racing the next addition to the platform. Privacy that starts from off doesn't have to run.

Source