Researchers Haj Bakry and Mysk have disclosed that Apple’s iCloud Private Relay can expose a user’s real IP address through multiple WebKit proxy bypasses. The dual-hop privacy feature, introduced with iOS 15 and intended so that no single party — including Apple — can determine a user’s origin, is undermined by three leaking vectors affecting iOS, macOS, and all WebKit-based browsers.
The Dual-Hop iCloud Private Relay Architecture and Its Intended Assurance
iCloud Private Relay routes Safari traffic through two relay hops so that neither a single server nor Apple can link a user to a request. The design assumes the browsing flow stays entirely inside the relayed tunnel. The bypasses break that assumption by leaking connection metadata outside the protected channel, which is the precise property the feature was built to prevent.
The Three Leak Vectors: DNS Prefetching, WebAuthn, and WebTransport
The researchers identified DNS prefetching, WebAuthn Related Origin Requests, and WebTransport as channels that leak connection metadata outside the relayed flow. In each case a direct connection or name-resolution query reveals the user’s real IP to a website or an observer, defeating the anonymity the relay promises. These are all auxiliary subsystems that the relay wrapping does not fully capture, which is why the leaks persist.
The Exposure Extends to Safari and Every WebKit-Based Browser
The issue affects iOS and macOS and all WebKit-based browsers, including Safari and WebKit shells. Because the leaks arise in the WebKit engine rather than in a single app, any WebKit-derived browser inherits the exposure, widening the pool of affected users well beyond the default Safari install. A user who switched browsers for privacy gains nothing if the replacement is built on the same engine.
What the Private Relay Bypasses Mean for Privacy-Conscious Users
For users relying on Private Relay for privacy, the finding limits the anonymity claim: real IPs can be exposed to websites and to observers through several channels, defeating the protection in exactly the scenario where the user hoped to hide their address. The feature still hides the origin from the destination site in the normal flow, but the bypass shows that assumption only holds for the connections the relay actually manages.
Acting on the Relay: Disabling DNS Prefetching and Awaiting Apple
Affected users should treat the feature as best-effort privacy rather than absolute anonymity, disable DNS prefetching where the browser exposes the option, and await Apple’s fixes for the three bypass vectors. Users of WebKit-derived browsers should assume the exposure is shared, because the leak sits in the same engine rather than in a per-app configuration.
The disclosure is notable less for a novel exploit than for the gap between a privacy feature’s marketed promise and its implementation. A dual-hop design only hides a user’s origin if every connection stays inside the relays; the moment an auxiliary network service bypasses it, the anonymity guarantee weakens. For privacy-conscious users the practical lesson is that a privacy feature is only as strong as its least-protected connection path, so the fix is as much about disabling the adjacent subsystems as about waiting for a patch. Until Apple closes all three WebKit seams, Private Relay is best understood as a privacy convenience with limits rather than complete protection against IP exposure.
The trio of vectors also shows how hard it is to make a privacy boundary airtight once a platform inherits a large engine. Each bypass reflects a subsystem that predates the relay and was never designed to send traffic through it, so closing the leak means changing behavior those subsystems were built to have. That is likely why the researchers describe the issue as affecting all WebKit-based browsers rather than a specific app: the fix has to live in the engine, not in a Safari-only configuration. Until Apple ships that engine-level change, users who need strong IP privacy for a specific task — such as handling an account that tracks sign-in geography or filtering by source address — should treat the relay as a layer to supplement, not a guarantee to rely on, and should test any particular site after enabling the feature.
