WebKit Leaks Real IP and DNS Around Proxies and iCloud Private Relay

A WebKit IP and DNS leak is undoing the privacy that proxy browsers on iOS are supposed to provide. Researchers at Mysk published findings on 4 August 2026 showing that three separate WebKit features open connections straight from the device, ignoring the proxy the browser was told to use. The same three paths also escape Apple's iCloud Private Relay.

Nothing here is a remote exploit. A page does not have to break anything: it simply uses ordinary web platform features and watches where the traffic arrives from.

The three features that walk around the proxy

DNS prefetch is a speed optimisation. A page hints that it will soon need a hostname, and the engine resolves it early. On iOS that resolution runs through the device's normal DNS path rather than the proxy. A site can put a unique hostname in the hint for every visitor, then read the queries as they land on its own authoritative name server, straight from the visitor's real network.

WebAuthn related origin requests leak differently. WebKit hands the passkey ceremony to the operating system's credential service, and that service fetches the site's /.well-known/webauthn file itself. The request comes from the system, not from the browser, so the browser's proxy settings never enter the picture.

WebTransport is the bluntest of the three. Creating one opens a QUIC connection directly from the device to the destination, with no proxy in between.

Why iCloud Private Relay does not save you here

Private Relay is often described as a VPN for Safari. It is not. It proxies Safari's page traffic through two hops so that no single party sees both who you are and what you requested. That protection covers the ordinary page-loading path, and all three leaks live outside it. When the operating system's credential service or a QUIC socket goes out on its own, Private Relay is not in the loop at all.

The same reasoning explains why the problem is worse on iPhone than anywhere else. App Store rules require every iOS browser to use WebKit, so a privacy-focused browser cannot swap in an engine that routes these paths correctly. Tor-based browsers for iOS inherit the leak by construction, and so does any app that builds anonymity on top of an in-app proxy.

What is actually being fixed

Mitigation so far comes from app developers rather than from the engine. Psylo shipped version 1.3.1, which strips dns-prefetch hints from pages and turns WebTransport and WebAuthn off by default, leaving them as opt-in switches. That is a workaround at the app layer: each affected browser has to notice the problem and disable useful features one by one. There is no public statement from Apple and no announced WebKit change addressing the three paths together.

Why a system tunnel is not affected

The distinction that matters here is where privacy is enforced. A proxy configured inside a browser only covers the traffic that browser chooses to send through it, so anything opened by another component of the system slips past. A full tunnel is enforced by the operating system's network stack instead: every packet from every process leaves through the same interface, whether it came from page loading, a credential service or a raw QUIC socket. That is why full-tunnel VPNs are untouched by all three leaks while in-browser proxies are not, and it is a useful reminder that browser-level privacy and network-level privacy solve different problems.

For anyone relying on a proxy browser today, the practical steps are small but real: update the app if its developer has shipped a mitigation, avoid treating Private Relay as an anonymity tool, and check what your browser actually exposes rather than trusting the indicator in the interface.