Apple's paid IP tracking protection can be bypassed – by any website that offers passkeys or even pretends to. Security researchers have discovered three ways to obtain the real IP address. No visible indication of this occurs.
Tommy Mysk and Talal Haj Bakry have described in a detailed analysis how this protection can be circumvented. The core of their argument: Any website that supports passkeys, or even pretends to, can see the real IP address – even if private relay is enabled.
This affects a paid component of iCloud+. The service's capabilities and limitations are often misunderstood – our comparison of iCloud Private Relay and traditional VPN services clarifies the difference. The newly discovered vulnerabilities further blur this line.
Key Facts at a Glance
- Websites can read the real IP address even when a private relay is active.
- The attack uses the WebAuthn passkey standard and requires no user interaction.
- Two other WebKit functions also reveal IP or DNS data.
- Third-party browsers are also affected on the iPhone because they have to use WebKit in most countries.
- An update is pending, but a timeframe for it is unknown.
How the attack works
Passkeys store a private key on the device, not in the browser. When a website initiates a passkey login, WebKit forwards the process to the operating system's authentication service. This service then makes the HTTPS request itself – directly from the device and without being aware that the app has configured a proxy.
This means the request never passes through the protected path of the private relay. The requested server sees the device's real IP address.
The crucial point for practical application: The process can be configured so that no interface appears at all. There's no passkey dialog, no confirmation prompt, no notification. Anyone accessing a specially prepared page won't notice anything. Our guide to passwordless login on Apple devices describes how passwordless login works normally.
Three leaks instead of one
In addition to the passkey method, the researchers found two other functions in WebKit that expose data to the outside world.
| How to get there | What is revealed | Since |
|---|---|---|
| WebAuthn via the login service | real IP address | consisting |
| DNS prefetching | the DNS servers actually used | iOS 26 |
| WebTransport | IP address | iOS 26.4 |
Two of the three methods only emerged with newer iOS versions. They were implemented for faster page loading and modern network connections – and thus counteract the protection that Apple sells elsewhere.
Why the iPhone is more affected than the Mac
Because the problem lies within WebKit itself, switching browsers on iPhones won't help in most countries: There, all browsers must use Apple's engine. This also affects at least one Tor browser, the Onion Browser – ironically, an application whose sole purpose is to conceal its origin.
The situation is different in the EU. Since the Digital Markets Act, providers are allowed to use their own browser engines, so the WebKit requirement no longer applies. In practice, this has changed little so far, because hardly any providers have switched, and Safari itself remains affected in any case. A recent study revealed further consequences of engine binding, showing that the WebKit requirement costs iOS browsers almost 30 percent of their performance.
How Apple reacted
The accounts diverge here. According to the researchers, Apple described the problem as serious but did not provide a timeline for a fix – and nevertheless released the report. The company told 404 Media only that it was investigating the report. Both statements come from the same source and are not mutually exclusive, but they paint different pictures of the urgency.
One clue lies in the recent past. In early July, a security vulnerability in the "Hide Email Address" feature was discovered, which allowed real email addresses to be identified. Apple patched it three weeks later. However, a similar speed of action for a vulnerability deeply embedded in the engine would be an optimistic assumption.
What will help now
The researchers have set up a test page where users can check whether their own address is being leaked. It runs on the domain of a privacy app from the same company – a commercial background that should be considered when reading the results, even if it doesn't invalidate the technical analysis.
Until an update is available, there's only one solution: anyone who wants to reliably hide their IP address needs a system-wide VPN. Private Relay only protects Safari traffic anyway and was never intended as a full-fledged replacement – this vulnerability only makes the difference more painfully obvious. If you rely on unfamiliar networks while traveling, the points in our security checklist for iPhone and MacBook remain unchanged, just with a VPN instead of Private Relay.
Why this weighs more than an ordinary bug
Private Relay isn't a free extra; it's part of a subscription. Those who pay for it are buying a promise: their address will remain hidden. However, this promise can be circumvented by a feature that Apple itself promotes as a secure alternative to a password.
Furthermore, there's the structure of the problem. Two of the three workarounds only emerged with iOS 26 and 26.4, meaning they were features Apple deliberately added. This suggests less of an overlooked programming error than that private relay functionality wasn't consistently considered when implementing new network features.
What remains open
It remains unclear whether Apple will close the vulnerabilities individually or fundamentally overhaul how WebKit handles proxy configurations. Only the latter would prevent the next network feature from repeating the same pattern. No date has been set for this. (Image: Apfelpatient)
- Ted Lasso Season 4 is here: Ted trains a women's team
- Foldable smartphones: Market expected to grow by 20 percent
- Apple is preparing for its September event: the date is approaching
