Security researchers Talal Haj Bakry and Tommy Mysk have identified a group of WebKit flaws that can cause Apple's iCloud Private Relay to fail at hiding a user's real IP address from websites. The findings, published on the researchers' blog on August 4, 2026, were independently verified by 404 Media and have since been acknowledged by Apple, which told 404 Media it is investigating the report (Engadget).

Private Relay is an opt-in iCloud+ feature that hides a user's IP address while browsing in Safari. Think of it as a partial privacy shield: it routes your Safari web traffic through two relay servers, so the website you visit sees a relay's IP, not yours. But as TechCrunch described in its coverage, the feature can be circumvented to leak the user's real IP address (TechCrunch). The root of the problem lies in WebKit's architecture and in Private Relay's scope: it covers Safari's web traffic rather than functioning as a full-device VPN. Any network connection that WebKit initiates outside the proxied web traffic path bypasses Private Relay entirely.

The researchers detailed two specific ways this happens. The first involves passkeys — a phishing-resistant replacement for passwords. When a user authenticates to a website using a passkey in Safari, WebKit triggers an authentication request outside the browser's normal web traffic. Because Private Relay only proxies Safari's web traffic, that out-of-band authentication request carries the device's real IP address. A website or service operator on the receiving end can therefore learn the user's actual IP even though Private Relay is active (Engadget; mysk.blog).

The second vector involves WebTransport, a newer web protocol for direct, low-latency connections between a browser and a server. WebKit builds the WebTransport connection outside the web traffic that Private Relay proxies, so a WebTransport server can observe the device's real IP address directly (mysk.blog).

Because the flaw resides in WebKit rather than in Safari-specific code, the impact extends beyond Apple's own browser. All iOS browsers are required to use WebKit under Apple's platform rules. That means privacy-focused browsers, including OnionBrowser and the researchers' own Psylo browser, are also affected when passkeys are used (Engadget). The researchers stated in a post on X that they had contacted OnionBrowser and the Tor Project to share their findings and possible solutions.

The researchers also cited a historical precedent to set expectations around remediation timelines. Another research team discovered a vulnerability in iCloud Hide My Email in mid-2025; Apple did not fix that issue for approximately a year (Engadget; 404 Media). The implication is that WebKit-level fixes for the Private Relay leak may not arrive quickly, even with Apple now actively investigating.

The broader context here is an architectural tension that this vulnerability exposes. Private Relay was designed as a lightweight, Safari-scoped privacy layer rather than a system-wide VPN. That design choice keeps latency low and avoids the battery and compatibility costs of tunneling all device traffic through dual-hop proxies. But it also means that any WebKit subsystem that opens a connection outside the proxied path, whether for passkey authentication or WebTransport, operates outside Private Relay's threat model entirely. The feature's privacy guarantee is only as strong as the narrowest interpretation of "Safari web traffic."

For iOS users who rely on privacy-focused browsers specifically to avoid IP exposure, the passkey vector is particularly consequential. A user who opens OnionBrowser expecting Tor-level IP obfuscation can still leak their real IP the moment they authenticate with a passkey, because the underlying WebKit engine handles that authentication outside both the Tor circuit and Private Relay's proxy path. The choice of browser does not help.

The passkey vector also raises questions about the intersection of Apple's two marquee privacy features. Passkeys are positioned as a phishing-resistant replacement for passwords, and Private Relay is positioned as a browsing-privacy tool. Both work as designed in isolation. The leak occurs at their intersection, where WebKit's handling of passkey authentication creates a traffic path that neither feature accounts for.

For technology professionals evaluating their threat models, the practical takeaway is straightforward. Private Relay should not be relied upon as a complete IP-masking solution on iOS, particularly for users who authenticate with passkeys or encounter WebTransport endpoints. A full-device VPN or Tor remains the more robust option when IP-level privacy is a hard requirement. Until Apple ships a WebKit-level fix, the gap between Private Relay's stated privacy guarantee and its actual coverage is something users and security teams should factor into their assessments.