Security researchers Tommy Mysk and Talal Haj Bakry have documented a way for websites to read the real IP address of an iPhone user who has iCloud Private Relay turned on. The mechanism is passkeys, and the reason it works says more about how iOS is built than about any single bug.
Their summary, as reported by 9to5Mac, is that any site which supports passkeys, or merely claims to, can see the address. That word is doing a lot of work.
Pretending is enough
A leak that fires only on legitimate passkey sign-ins would be bad. A leak that fires when a page simply advertises passkey support is a different category of problem, because it means any page can trigger it deliberately. There's no sign-in to complete and nothing for the visitor to click wrong. The site claims a capability, the device responds, and the address is out.
That's the difference between a flaw someone might stumble into and a tool someone can build a business on. Ad tech has spent a decade hunting for stable identifiers that survive privacy features, and a real IP address behind an active Private Relay session is precisely that.
Why Private Relay never sees the request
The researchers explain that the passkey fetch is issued by the operating system's credential service and not by Safari. Private Relay proxies Safari's traffic. A request that originates outside the browser never enters the proxied path, so the destination server sees the device directly.
This is worth understanding because it isn't the kind of bug you patch in a network stack. Private Relay is doing its job correctly for everything routed through it. The problem is a boundary: passkeys, by design, hand part of the flow to the system so credentials never touch the page. That design is good for credential security and it happens to open a door around the proxy. Two features built to protect people, each working as specified, and the gap sits between them.
It's also worth being precise about what Private Relay ever promised. It is not a VPN. It masks the address for Safari traffic, and a VPN operates at the system level across everything. Plenty of people have been sold the former as though it were the latter, and this is the sort of moment when that gap gets expensive.
The part that has no workaround
Here's what elevates this above a normal disclosure. On iOS, in most countries, every browser is required to use Apple's WebKit engine. Chrome on iPhone is WebKit. Firefox on iPhone is WebKit. So is every privacy-first browser on the platform.
Which means the usual advice fails. Normally a WebKit flaw is answered with "use a different engine," and on iOS there is no different engine to use. The researchers found the problem reaches OnionBrowser, a Tor browser for iOS, where exposing a real address defeats the entire point of the tool. They reported it to the Tor Project, which reportedly described it as dire and gave no timeline, while agreeing the researchers could publish. Their own browser, Psylo, is affected too.
A single-vendor engine requirement means a single bug becomes a platform-wide condition with no user-side escape. That has been the argument against the WebKit rule for years, usually made about web features and developer choice. This is the security version of it, and it's more persuasive.
What to do while waiting
Mysk filed a report with Apple, which says a fix is planned for autumn 2026. Engadget notes the exposure isn't limited to Safari for the same engine reason. The researchers have published a test page so people can check their own devices.
If your threat model is advertising, this is annoying and a fix is coming. If your threat model involves anyone who might act on knowing where you are, a system-level VPN covers what Private Relay does not, and it covers it for every app rather than one browser. Turning off passkeys is technically an option and a poor trade, since passkeys defend against phishing and credential theft, which harm far more people than IP exposure does.
This also follows a bug in Hide My Email that exposed real addresses and was fixed last month. One incident is a bug. Two in consecutive months, both in features people chose specifically for privacy, starts to look like the privacy suite is getting less scrutiny than the things it protects.