iCloud Private Relay Bypassed: WebKit Flaw Exposes Real IP Addresses

For years, Apple has built its global brand identity on an uncompromising commitment to user privacy, positioning its hardware and software ecosystem as a fortress against digital surveillance. However, a disclosure by cybersecurity researchers Tommy Mysk and Talal Haj Bakry has revealed significant vulnerabilities in Apple’s flagship privacy tool, iCloud Private Relay. Designed as a core benefit for paid iCloud+ subscribers, the feature promises to mask a user’s real IP address and obscure web browsing metadata from ISPs, advertisers, and destination websites. Yet, critical technical flaws in Apple’s WebKit browser engine allow third-party sites to systematically bypass these protections. By triggering unproxied background connections, malicious domains can expose a user’s authentic network IP address and DNS details—completely undermining the privacy guarantees of iCloud Private Relay across iOS, iPadOS, and macOS.

The Architectural Limits of iCloud Private Relay

To understand how these leak vectors operate, it is essential to examine the underlying architecture of iCloud Private Relay. Introduced alongside iOS 15, the service was created to provide seamless, low-latency privacy protections for Safari web browsing. Unlike traditional Virtual Private Networks (VPNs) that encrypt and tunnel all network traffic at the operating system kernel level, Apple’s implementation operates specifically at the application layer using a specialized dual-hop proxy architecture.

When a user browses the web in Safari with the service enabled, outgoing requests are directed through two separate, isolated relay nodes:

• The Ingress Relay (First Hop): Managed directly by Apple, this server receives the user’s initial network connection. It authenticates the user’s iCloud+ subscription and knows their authentic IP address. However, because the payload is encrypted using Transport Layer Security (TLS), Apple cannot inspect the specific URL or web page being requested.
• The Egress Relay (Second Hop): Managed by independent third-party network providers—including Fastly, Akamai, and Cloudflare—this relay decrypts the web destination and assigns a temporary, regionally accurate IP address. Crucially, the egress relay never receives the user’s real IP address, ensuring that neither Apple nor the destination server can simultaneously see who the user is and where they are navigating online.

While this multi-tier infrastructure offers strong isolation against conventional network profiling, its fundamental vulnerability lies in its application-layer dependency. Because iCloud Private Relay relies on WebKit to route traffic into the dual-hop pipeline, any network call initiated outside WebKit’s proxied execution context bypasses the dual-hop system entirely, transmitting the device’s unmasked IP address across the open internet.

Deconstructing the Three WebKit Vulnerability Vectors

The research published by Mysk and Bakry demonstrates that the failure does not stem from compromised relay servers, but from structural design flaws in WebKit—the open-source browser engine that powers Safari and is mandated by Apple for all iOS web browsers. The researchers identified three specific WebKit mechanisms where network traffic bypasses proxy rules configured via WKWebsiteDataStore.proxyConfigurations.

1. WebAuthn and Passkey Related Origin Requests

The most immediate and critical leak mechanism involves WebKit’s handling of the WebAuthn standard, which forms the underlying infrastructure for passkey authentication. Passkeys store private cryptographic credentials in the local operating system keychain or a secure hardware enclave, operating outside the browser process itself. When a