Three features in Apple's WebKit browser engine route around iCloud Private Relay and proxy browsers on iOS 18, 26.0, and 26.4. System level VPNs are unaffected, and one proxy browser already ships mitigations.
System-level VPNs tunnel everything the device sends, so they still hide the real IP even when WebKit opens its own network paths. iCloud Private Relay and proxy browsers don't sit that low. They are apps that route traffic through an intermediary server rather than connecting directly, and they ride on top of Apple's WebKit engine. On iOS, WebKit is the only engine Apple permits third-party browsers to use. On August 4, the iOS security research team Mysk published a proof-of-concept and three code paths that bypass that layer entirely, exposing the real IP address or DNS resolver the privacy tool was supposed to hide.
The disclosure names three WebKit features that route around the WKWebsiteDataStore.proxyConfigurations API. DNS prefetching, which arrived in iOS 26.0, leaks the device's real DNS resolvers. WebAuthn Related Origin Requests, available since iOS 18, exposes the real IP. WebTransport, added in iOS 26.4, exposes the real IP through a different transport. None of these features were designed as privacy bypasses, but all three open network channels that don't consult the proxy configuration WebKit was supposed to honor.
The leaks affect every iOS browser, the same code paths expose iCloud Private Relay since it runs on the same WebKit network stack. macOS WebKit-based browsers are similarly exposed, though macOS users who install Chrome, Firefox, or another non-WebKit browser escape the issue. System-level VPNs are not affected because they tunnel the device's entire connection at the operating system, below the layer where WebKit makes its own network decisions.
The boundary is stack layer, not tool prestige. A VPN that installs a system tunnel can override whatever transport WebKit tries to use; a proxy browser or Private Relay is asking the engine to be a good citizen, and the engine now has three new places to be a bad one. Wire coverage will likely tell readers that "WebKit leaks your IP." The more useful point is that the leak surface is whatever the browser engine can do without consulting the proxy configuration, and the engine now has three more knobs in iOS 18, 26.0, and 26.4 than it did in iOS 17.
The mitigation pattern is already in shipping code. Mysk's own browser, Psylo, released version 1.3.1 with three changes: it blocks <link rel="dns-prefetch"> hints at the proxy layer, disables WebTransport by default, and disables WebAuthn Related Origin Requests by default. Each setting has a per-site opt-in toggle, so users can re-enable them on sites that legitimately need WebTransport for low-latency streaming or WebAuthn for hardware-key sign-in. The team has also contacted the Tor Project and Onion Browser developers about the same code paths.
A first-party signal exists in the WebKit bug tracker: bug 285744 is filed as a request to add explicit <link rel=dns-prefetch> support while removing the existing privacy-invasive prefetching path. That's a request for the design change, not an Apple fix or timeline, and the same goes for the WebAuthn and WebTransport entries that document the underlying behavior. WebKit's Safari 18.0 and Safari 26.4 release notes confirm when each feature shipped, which is the only schedule the public can anchor to.
The proof-of-concept is public at leaks.psylo.app, the iOS version anchors are specific, and the three mitigations are present in a shipped product rather than a theoretical patch. That doesn't make the report neutral, but it does make it testable: any other WebKit-based browser on iOS or macOS can be checked against the same three code paths today. Reception on Hacker News sat at 16 points at the time of writing, which fits the disclosure's shape: a narrow, specific finding that hands the threat-model line to the reader rather than a panic-grade vulnerability that needs immediate patching.
For users of iCloud Private Relay and proxy browsers, the practical question is what their threat model was supposed to protect. If the goal was to hide the real IP from the destination site, the three WebKit code paths are exactly the kind of leak surface that model can't survive, and the fix has to come from the tool disabling the features or the OS layer tunneling them. If the goal was the dual-hop egress that Private Relay sells separately from a VPN, that part still functions as designed. The line between the two is what Mysk just redrew, and it lives one stack layer below where most product copy draws it.