When a site supports — or merely claims to support — passkeys, iOS's system credential service fetches a validation file directly from the device's real IP address, completely bypassing Private Relay's proxy path . This request is issued by the operating system's credential manager, not by Safari, so it never enters Private Relay's protected routing
. Any website can trigger this leak without any user interaction; it does not require an actual login attempt
. Mysk summarized the problem bluntly: "In short: any website that supports, or pretends to support, passkeys can see the user's real IP address despite having iCloud Private Relay on"
.
WebKit resolves hostnames through the device's normal DNS path, revealing the user's real DNS servers instead of the proxy's . This exposes the user's true IP and DNS information even when Private Relay is active
. A site can plant a unique address and simply watch the DNS request arrive from the user's real network
.
WebTransport sessions initiated within the browser can bypass Private Relay's proxy by opening a direct HTTP/3 connection, leaking the device's real network information .
Mysk set up a public test website where anyone can check if their real IP address leaks despite Private Relay being enabled. TechCrunch verified that the site was able to reveal their real IP address . Beyond Safari, the issues also impact OnionBrowser (an iOS Tor browser) and other proxy-based browsers due to the WebKit mandate
.
Since Apple has not yet released a patch, the only reliable mitigation is to use a full-device VPN that does not rely on WebKit's proxy settings. The third-party browser Psylo released version 1.3.1, which blocks dns-prefetch hints and disables WebTransport as a workaround .