Apple WebKit Flaws Can Leak Real IP Addresses Despite iCloud Private Relay and Proxy Browsers

Apple’s WebKit browser engine contains three networking behaviors that can expose a user’s real IP address or DNS resolver even when browsing through proxy-based privacy tools, according to research published by security researchers Talal Haj Bakry and Tommy Mysk. The findings affect Safari’s iCloud Private Relay as well as every iOS browser that relies on WebKit’s application-level proxy APIs, including privacy-focused browsers such as Onion Browser, Orion, Psylo, and other browsers built on Apple’s mandatory browser engine.

The research highlights an important distinction between application-level proxying and system-wide VPN tunneling. While many users assume that enabling iCloud Private Relay or using a proxy browser completely hides their network identity, the researchers discovered that several WebKit features create network connections outside the browser’s normal networking path. Because these requests never pass through the configured proxy, remote servers can observe the device’s actual IP address or DNS infrastructure instead of the proxy’s.

Unlike traditional browser vulnerabilities that require code execution or exploitation, these behaviors are triggered by legitimate web platform features. In some cases, simply opening a website is enough to generate a direct network request from the device. Although the issues do not enable arbitrary code execution or compromise the operating system, they significantly weaken the privacy guarantees users expect from proxy-based browsing.

At a Glance

Researchers identified three separate mechanisms capable of bypassing WebKit’s proxy configuration:

• DNS Prefetching can reveal the user’s actual DNS infrastructure.
• WebAuthn Related Origin Requests can disclose the device’s public IP address.
• WebTransport can establish direct HTTP/3 connections that bypass the configured proxy.

The researchers also confirmed that these behaviors affect Apple’s iCloud Private Relay because the requests occur outside Safari’s standard proxied browsing pipeline. In contrast, system-wide VPNs remain unaffected because they tunnel all device traffic at the operating system level rather than relying on browser-specific proxy settings.

Why This Matters

Privacy tools generally rely on a simple assumption: websites should only see the address of the intermediary server, not the user’s own network. That assumption is fundamental to proxy browsers, Tor-style routing, anonymous browsing services, and Apple’s iCloud Private Relay.

On iOS, however, every browser must use Apple’s WebKit engine. Even browsers that advertise stronger privacy protections cannot replace the underlying networking implementation. Since Apple prohibits alternative browser engines on iOS, any flaw inside WebKit has platform-wide consequences.

The research originated after a Psylo user reported intermittent DNS leaks. Initially, only certain websites appeared to bypass the browser’s proxy, suggesting the issue depended on specific web technologies rather than a complete failure of proxy routing. A deeper investigation revealed that the DNS leak was only one symptom of a broader architectural problem involving three independent WebKit features.

This means the problem is not limited to one browser. Instead, it stems from how WebKit delegates certain networking tasks to other components within Apple’s software stack.

Understanding Proxy Browsers on iOS

Unlike desktop browsers that can implement their own networking stacks, iOS browsers depend heavily on WebKit. Apple introduced the WKWebsiteDataStore.proxyConfigurations API to allow applications to route browser traffic through HTTP, HTTPS, or SOCKS proxies. Privacy-oriented browsers use this API so that every network request initiated by a webpage should pass through the configured proxy before reaching its destination.

Under normal circumstances, the process is straightforward. A webpage requests a resource, WebKit sends the request through the configured proxy, and the destination website sees only the proxy server’s IP address. DNS lookups, HTTPS requests, JavaScript resources, images, and other web content are all expected to follow the same route.

The researchers found that three WebKit features ignore this proxy configuration entirely. Instead of using the browser’s networking path, they invoke separate networking components within the operating system. Because those components are unaware of the browser’s proxy settings, they establish direct connections from the user’s device.

From a privacy perspective, this distinction is critical. Even if only one request bypasses the proxy, that single request may be enough for a website to associate anonymous browsing activity with the user’s actual network.

Why iCloud Private Relay Is Also Affected

Apple markets iCloud Private Relay as a privacy feature that separates a user’s identity from the websites they visit. Available to iCloud+ subscribers, the service routes Safari traffic through a two-hop architecture. Apple knows the user’s IP address but not the destination website, while the second relay knows the destination but not the user’s identity. This separation prevents any single party from linking both pieces of information.

The newly disclosed behaviors operate outside that protected browsing path.

Private Relay only processes traffic that Safari sends through its standard networking pipeline. When WebKit hands a task to another operating system component, that request never enters the relay infrastructure. Instead, it travels directly from the device to the destination server, exposing information that Private Relay was designed to conceal.

This architectural limitation explains why the researchers observed the same privacy leaks even when Private Relay remained enabled throughout testing.

It is equally important to understand what is not affected. System-wide VPN applications operate below individual browsers and encrypt all network traffic leaving the device. Since every outgoing packet traverses the VPN tunnel regardless of which software generates it, these WebKit-specific bypasses cannot escape the VPN.

DNS Prefetching: The First Leak

The first issue involves DNS prefetching, a longstanding web optimization technique designed to reduce page loading times.

Normally, when a browser encounters a hyperlink, it waits until the user clicks before resolving the destination’s domain name into an IP address. DNS prefetching accelerates this process by resolving hostnames proactively. Website developers enable it using the HTML element:

<link rel="dns-prefetch" href="//example.com">

When implemented correctly, this optimization reduces latency because the DNS lookup has already completed before the browser attempts to establish a connection.

The researchers discovered that WebKit performs these prefetch lookups using the device’s normal DNS resolver rather than the browser’s configured proxy. As a result, DNS requests originate directly from the user’s network.

While a DNS lookup alone does not expose the public IP address used for browsing, it reveals information that privacy tools are specifically intended to hide. Websites operating their own authoritative DNS servers can generate unique hostnames for every visitor and observe where DNS queries originate. Instead of receiving requests from the proxy infrastructure, they receive them from the visitor’s actual ISP or enterprise DNS resolver.

For organizations that maintain detailed DNS logs, this creates a reliable mechanism for correlating browsing activity with individual users.

The researchers noted that this explains why only some websites triggered the original DNS leak report. DNS prefetching is optional and must be explicitly enabled by the website. Pages that never use <link rel="dns-prefetch"> do not generate these additional lookups.

Although DNS prefetching has existed on desktop browsers for years, Apple only enabled explicit support for this HTML feature on iOS relatively recently. That implementation now performs lookups outside WebKit’s proxy-aware networking path, creating the observed privacy leak.

From a practical perspective, exploitation is straightforward. A website embeds uniquely generated hostnames inside DNS prefetch tags. When the page loads, the visitor’s device immediately resolves those hostnames using its local DNS infrastructure. The website’s authoritative DNS server receives the query and can determine that it originated from the user’s real network rather than the configured proxy or Private Relay.

Unlike JavaScript fingerprinting or browser fingerprint collection, this behavior requires no user interaction. Simply loading a page containing DNS prefetch hints is sufficient.

Although the disclosed behavior primarily reveals DNS information rather than the browsing IP itself, DNS infrastructure often exposes valuable metadata about a user or organization. Enterprise DNS resolvers, ISP-operated recursive resolvers, and regional public DNS services frequently provide enough information to narrow a visitor’s geographic location or organizational affiliation. Combined with other browser fingerprinting techniques, such information can strengthen user correlation across browsing sessions even when an application-level proxy is enabled.

The discovery also demonstrates a broader architectural issue. Rather than representing an isolated implementation bug, DNS prefetching shows that not every networking feature inside WebKit inherits the browser’s proxy configuration. Once researchers identified this inconsistency, they expanded their investigation to other WebKit subsystems and ultimately uncovered two additional mechanisms capable of bypassing the browser’s privacy protections.

WebAuthn Related Origin Requests: Passkey Validation Outside the Browser

The second issue uncovered by the researchers is arguably more concerning because it can expose a user’s public IP address rather than just their DNS infrastructure. The leak originates from WebAuthn Related Origin Requests, a feature introduced to support modern passkey deployments across multiple domains owned by the same organization.

To understand why this happens, it helps to first understand how WebAuthn normally works.

Web Authentication (WebAuthn) is the W3C standard that enables passwordless authentication using passkeys and hardware security keys. A passkey is generally tied to a single Relying Party Identifier (RP ID), which is usually the website’s domain. This binding prevents credentials created for one website from being used by another, protecting users from phishing attacks.

Large organizations, however, often operate multiple domains. A company may authenticate users on login.example.com, allow account management on account.example.com, and host applications on app.example.com. Managing separate passkeys for every domain would create a poor user experience, so the WebAuthn specification introduced Related Origin Requests.

When a website attempts to use a passkey associated with a different RP ID, the browser first needs to verify that the requesting origin is authorized to do so. It performs this validation by retrieving a JSON document located at:

https://<rpId>/.well-known/webauthn

The file specifies which origins are permitted to use credentials belonging to that relying party.

The researchers discovered that this validation request is not performed through WebKit’s normal networking stack. Instead, WebKit delegates the authentication ceremony to Apple’s operating system credential service, which independently fetches the .well-known/webauthn file.

Because the operating system component has no knowledge of the proxy configured through WKWebsiteDataStore.proxyConfigurations, the HTTPS request originates directly from the device rather than the proxy server. The destination website therefore observes the user’s actual public IP address.

Even more importantly, this request can occur before any visible authentication prompt appears.

A webpage can initiate a conditional WebAuthn request that triggers the validation fetch in the background. Although the user is never prompted to authenticate unless they choose to continue, the network request itself has already been sent. Simply visiting a webpage that implements this functionality can therefore disclose the visitor’s real IP address without requiring them to click a button or attempt to sign in.

This behavior also explains why the researchers emphasized that normal browsing can trigger the leak. Users do not need to interact with a login page or use a passkey. Visiting a site that performs the validation process is sufficient.

Because Safari’s Private Relay only proxies traffic generated by its own browsing pipeline, these operating system credential service requests bypass the relay entirely. The destination server sees the device’s actual network address regardless of whether Private Relay is enabled.

WebTransport Creates Direct QUIC Connections

The third issue involves WebTransport, one of the web platform’s newest networking technologies.

WebTransport is designed for applications that require low-latency, bidirectional communication while avoiding some of the limitations of WebSockets. Built primarily on HTTP/3 and QUIC, it supports multiple independent streams, unreliable datagrams, and improved congestion handling. These characteristics make it attractive for cloud gaming, real-time collaboration, video conferencing, multiplayer games, streaming telemetry, and other latency-sensitive applications.

From a performance perspective, WebTransport represents a significant evolution of browser networking.

From a privacy perspective, however, the researchers found an unexpected problem.

When JavaScript creates a new WebTransport connection using:

new WebTransport("https://example.com")

WebKit establishes a direct HTTP/3 connection using Apple’s underlying networking framework. During this process, the browser’s configured application-level proxy is never applied.

Instead of routing the QUIC session through the proxy server, the operating system creates a direct connection from the user’s device to the destination server.

Consequently, the WebTransport server immediately learns the client’s real public IP address.

Like the previous two findings, this is not caused by an attacker breaking browser security. Rather, it results from different networking subsystems inside WebKit using different execution paths. Traditional webpage requests correctly inherit proxy settings, while certain specialized APIs create their own network sessions independently.

Since Apple’s Private Relay only handles Safari’s normal browsing traffic, WebTransport connections similarly fall outside the relay’s protected path.

The researchers did identify one notable exception. Onion Browser’s highest “Silver” security level enables Apple’s Lockdown Mode, which disables WebTransport altogether. Users operating at that security level are therefore protected against this specific leak, although the other issues remain unaffected.

Real-World Impact

The disclosure should not be interpreted as a complete failure of Apple’s privacy technologies.

Private Relay continues to conceal the user’s IP address for ordinary webpage loading, DNS resolution, and standard browser requests. Likewise, proxy browsers continue routing the overwhelming majority of browsing traffic through their configured proxy infrastructure.

The problem is that privacy guarantees are only as strong as the weakest networking path.

If even a single request bypasses the proxy, a website may obtain sufficient information to associate an anonymous browsing session with the user’s actual network.

For ordinary users, the practical risk depends on the websites they visit. Many sites never use DNS prefetch hints, WebTransport, or Related Origin Requests. Others may use one or more of these technologies without realizing they bypass proxy configurations.

For journalists, activists, researchers, whistleblowers, and individuals operating in high-risk environments, however, even a single unexpected IP disclosure can undermine carefully established anonymity.

The findings are particularly significant for iOS Tor browsers. Unlike Tor Browser on desktop platforms, which controls its own browser engine and networking stack, iOS browsers are required to use Apple’s WebKit engine. As a result, they inherit WebKit’s architectural behavior even when all conventional webpage traffic is correctly routed through Tor or another proxy.

The researchers informed both the Tor Project and the developers of Onion Browser so that they could evaluate potential mitigations.

Why VPNs Remain Unaffected

One of the most important conclusions from the research is that system-wide VPNs are not vulnerable to these leaks.

Application-level proxies operate within a specific browser or application. Individual software components must explicitly use the configured proxy for every network request they generate. If one subsystem ignores that configuration, traffic leaves the device directly.

VPNs operate much lower in the networking stack.

Instead of relying on individual applications to respect proxy settings, the operating system routes all outgoing packets through an encrypted tunnel before they reach the internet. Whether traffic originates from Safari, WebKit, Apple’s credential services, WebTransport, or another system process, it still traverses the VPN.

This architectural distinction explains why the disclosed behaviors affect proxy-based privacy tools but not properly configured VPN connections.

Mitigations

The researchers addressed the issues in Psylo 1.3.1 by disabling or blocking the affected features rather than attempting to modify WebKit itself.

DNS prefetch hints are now blocked, preventing websites from triggering direct DNS lookups. WebTransport and WebAuthn are disabled by default, with users able to re-enable them on a per-site basis if necessary. This approach preserves compatibility while ensuring privacy-sensitive users must explicitly opt into features that could weaken their anonymity.

For users of Safari and other WebKit-based browsers, there is currently no universal browser-side mitigation beyond software updates from Apple. Users whose threat model requires preventing any possibility of IP disclosure should consider using a trusted system-wide VPN, which tunnels all network traffic regardless of which operating system component generates it.

Organizations deploying iOS devices in security-sensitive environments should also recognize the distinction between application-level proxies and VPN-based network controls. While proxies remain valuable for many use cases, they should not be treated as equivalent to system-wide traffic tunneling when anonymity is a primary objective.

Final Thoughts

The research by Talal Haj Bakry and Tommy Mysk demonstrates how privacy guarantees can be weakened not by a traditional software vulnerability, but by subtle architectural boundaries between browser components and operating system services. DNS Prefetching, WebAuthn Related Origin Requests, and WebTransport each serve legitimate purposes within the modern web platform, yet all three establish network activity outside WebKit’s proxy-aware browsing pipeline.

Although these behaviors do not permit remote code execution or compromise the integrity of iOS or macOS, they expose information that privacy-focused users reasonably expect to remain hidden. Because every browser on iOS relies on WebKit, the impact extends well beyond Safari to virtually the entire ecosystem of proxy-based browsers available on Apple’s mobile platform.

For most users, the immediate risk is limited and depends on whether the websites they visit employ these features. For users who depend on proxy-based anonymity, however, the findings underscore an important lesson: browser-level privacy protections and application proxies are not interchangeable with system-wide network tunneling. Until the underlying behavior is addressed by Apple, VPNs remain the more robust option for ensuring that every network request, regardless of which software component generates it, follows the same protected path.