The discovery of proxy bypasses in Apple’s WebKit browser engine demonstrates how privacy protections can fail when individual browser features do not consistently follow the same network-routing policy. Researchers Talal Haj Bakry and Tommy Mysk identified three WebKit mechanisms that can send traffic directly from an Apple device instead of routing it through the proxy configured by the browser. As a result, a website may be able to determine the user’s real network address even when Safari is using iCloud Private Relay or another WebKit-based browser is configured to use a privacy proxy. 

The issue affects DNS prefetching, WebAuthn Related Origin Requests and WebTransport. These are legitimate web capabilities designed to improve performance, support passkey authentication and enable modern low-latency communication. The problem is not that the features are inherently malicious, but that their network requests may follow a different path from ordinary browser traffic. A privacy system can protect most page requests correctly while still failing if one background feature quietly communicates outside the protected route.

This inconsistency creates a significant privacy concern because users generally understand a browser proxy or Private Relay as applying to the browsing session as a whole. They do not expect the protection to depend on which browser API a website decides to invoke. If ordinary HTTPS traffic uses the relay but a passkey-related validation request or WebTransport connection uses the device’s direct connection, the website may associate the relay address with the real address and defeat the intended separation.

iCloud Private Relay is designed to prevent any single party from seeing both the user’s identity and browsing destination. Safari traffic is passed through two separate relays. The first relay can see the user’s actual IP address but not the destination website, while the second relay connects to the website using a temporary address without learning the user’s original address. This design reduces the ability of websites, network providers and relay operators to combine identity, location and browsing activity.

The newly disclosed behaviour does not break the encryption or cryptography used by Private Relay. Instead, it causes selected traffic to avoid the relay architecture completely. This distinction is important because it shows that even a well-designed privacy service can be undermined by traffic generated elsewhere in the browser stack. The protected route remains secure, but the privacy guarantee becomes incomplete when another component opens a direct connection.

WebKit’s central role increases the impact

WebKit is the browser engine used by Safari and by browsers operating under Apple’s browser framework on iOS and iPadOS. This means the issue is not limited to users who consciously choose Safari. Chrome, Edge, Firefox, Brave and other browsers on these platforms rely on WebKit for webpage rendering and much of their networking behaviour.

A user may therefore switch browsers and reasonably assume that the underlying proxy behaviour will change, while the same WebKit-level weakness remains present. Browser branding can create an appearance of technical diversity even when the applications share the same underlying engine and operating-system services.

The issue also affects macOS applications and browsers that use WebKit proxy-configuration interfaces. Desktop applications frequently embed WebKit to display login pages, documentation, dashboards and web-based interfaces. If those applications depend on the same proxy assumptions, direct background requests may expose the device’s network even when the main application traffic appears protected.

Organizations should therefore assess exposure according to the WebKit framework and platform version rather than focusing only on the Safari application. Privacy and security controls need to account for every application that can render attacker-controlled web content through the affected engine.

DNS prefetching can reveal the user’s resolver path

DNS prefetching improves browsing performance by resolving domain names before the user actually opens the related link. A webpage can hint that certain hostnames may be needed, allowing the browser to resolve them in advance and reduce delay later.

The researchers found that WebKit could perform these DNS lookups through the device’s normal DNS route instead of the proxy selected by the browser. A malicious site can provide a unique hostname controlled by the attacker and observe which resolver or source network requests it.

Depending on the network architecture, this may expose the user’s actual public IP address directly or reveal information about the underlying internet provider and location. Even when the DNS request arrives through a recursive resolver, the result may still provide enough correlation to weaken the privacy expected from the proxy.

The request can occur automatically when the page loads. The victim does not need to click the link or approve a prompt. A background performance optimization therefore becomes a channel through which the site can test whether traffic is escaping the protected route.

This also demonstrates why DNS privacy must be considered alongside web traffic. Hiding the source address of HTTP requests provides incomplete protection if DNS queries associated with the same session travel through a directly observable path.

WebAuthn behaviour can leak IP addresses without passkey use

WebAuthn is the web standard used for phishing-resistant authentication methods such as passkeys and hardware security keys. It allows a website to request authentication through credentials securely bound to the legitimate domain.

The affected WebAuthn Related Origin Requests feature supports organizations that need credentials to work across related domains. The operating system may fetch a validation file to confirm that the domains are legitimately associated.

Researchers found that this validation request could be sent directly from the device instead of through the browser proxy. A malicious website can claim to support the relevant WebAuthn configuration and trigger the operating system to retrieve an attacker-controlled file.

The website can then observe the direct request and learn the visitor’s real IP address. The user does not need to possess a passkey, begin a login or approve authentication. Merely visiting the page may be sufficient for the website to initiate the validation request.

This makes the issue particularly notable because passkeys are generally promoted as a major improvement in authentication security. The authentication mechanism itself remains secure, but a supporting network operation can create a privacy leak unrelated to whether authentication succeeds.

Security features should not silently become tracking interfaces. Every external request initiated by authentication services must follow the privacy policy of the browser session or require an explicit and understandable exception.

WebTransport can establish a direct HTTP/3 connection

WebTransport provides low-latency, bidirectional communication between browsers and servers. It is intended for applications such as interactive streaming, gaming, real-time collaboration and other workloads that need communication capabilities beyond traditional request-and-response web traffic.

The technology generally uses HTTP/3 over QUIC, which operates over UDP. Many browser proxy systems were originally designed around HTTP and HTTPS traffic carried over TCP. If the proxy implementation does not support or intercept WebTransport correctly, WebKit may attempt to connect directly.

A malicious site can use this behaviour to establish a direct connection to an attacker-controlled server. The destination then sees the device’s actual public IP address rather than the temporary relay or proxy address shown by the main browsing traffic.

This highlights a recurring challenge as web standards expand. New protocols and transport mechanisms may bypass controls designed for older networking models. Privacy, filtering and monitoring systems must be updated whenever browsers gain a new way to communicate.

Simply stating that web traffic is proxied is no longer sufficient when a webpage can generate DNS, authentication, peer-to-peer and QUIC-based traffic through multiple framework components. The policy must be enforced at the network layer consistently, not implemented separately by each feature and left to chance.

The attack can correlate the proxy identity with the real network

An IP leak is most useful when the attacker can associate it with the visitor’s current browsing session. The disclosed techniques allow the malicious website to generate a unique request that is linked to the page already open through the proxy.

For example, the site can assign a unique subdomain or identifier to the visitor and cause one of the affected WebKit features to contact that destination outside the protected route. When the request arrives, the attacker can match it to the session using the relay address.

This reveals that the visitor using a particular temporary proxy address is actually connected through a particular household, mobile carrier, workplace or other network. The attacker can then combine that information with cookies, account details and browser fingerprints.

The leak does not necessarily reveal the user’s precise physical address, but public IP information can expose the internet provider, approximate region, organizational network and whether several sessions originate from the same connection. For users relying on Private Relay to reduce tracking or conceal a sensitive network location, that information may be significant.

The website must deliberately trigger and correlate the request, but no further user interaction is required. This makes the issue suitable for invisible tracking code embedded within an ordinary webpage.

Users may misunderstand the scope of Private Relay

Private Relay is a Safari privacy feature rather than a complete device-level VPN. It is designed primarily to protect supported Safari browsing and selected unencrypted application traffic, not every network connection generated by the device.

This scope has always created potential for misunderstanding. Users may see that Private Relay is enabled and assume that no website can discover their real network address. The disclosed WebKit behaviour makes the distinction more important because the bypass occurs within the browsing environment itself rather than through an obviously separate application.

A website loaded in Safari appears to be exactly the type of activity Private Relay is supposed to protect. Users cannot reasonably determine that one hidden request came from an operating-system credential service or transport implementation that did not use the same relay.

Privacy interfaces should therefore communicate not only whether a proxy is enabled but whether every network feature used by the current page is following it. A green status indicator is of limited value when selected browser APIs can operate outside the protected channel.

The issue also illustrates the difference between improving privacy and providing anonymity. Private Relay limits common forms of IP-based tracking but does not make a user unidentifiable. Account logins, browser fingerprinting, cookies and application behaviour can still reveal identity even when the IP address remains hidden.

A full-device VPN provides a stronger temporary mitigation

The researchers noted that the identified leaks are mitigated when the user connects through a properly configured full-device VPN. Even if WebKit bypasses the browser-level proxy, the operating system routes the direct request through the VPN interface, causing the destination to see the VPN address rather than the user’s ordinary public address.

This provides protection at a lower network layer. Browser features may disagree about proxy configuration, but their packets still leave through the device-wide encrypted tunnel.

However, VPNs introduce their own trust and configuration requirements. The VPN provider may be able to observe connection metadata, and poorly designed services may log activity, manipulate traffic or fail to route IPv6 and DNS correctly.

Users should rely on reputable providers and verify that the VPN protects DNS, IPv4 and IPv6 traffic. Kill-switch and always-on capabilities can help prevent traffic from reverting to the normal connection when the tunnel disconnects.

Organizations requiring reliable source-address protection should use managed device-level VPN or secure access software rather than depending solely on browser proxy settings. The configuration should be tested against multiple protocols, including UDP and HTTP/3, rather than validated only by opening an ordinary IP-checking website.

Proxy testing must include background browser features

Many users and administrators test a privacy service by visiting a website that displays the source IP address of the main HTTPS request. If that page shows the expected proxy address, they conclude that the configuration is working.

The WebKit findings demonstrate why this test is incomplete. The main request may be proxied correctly while DNS prefetching, WebAuthn validation or WebTransport exposes a different route.

Testing should therefore examine the complete set of network connections created by the page. DNS logs, packet captures and controlled destination servers can reveal whether any traffic leaves outside the intended tunnel.

Enterprise security teams should test browsers after operating-system and WebKit updates because new web capabilities can introduce additional protocols. Proxy compliance must be continuously verified rather than assumed from documentation.

Browser vendors should also maintain automated tests ensuring that every externally observable request follows the active privacy and proxy policy. A feature should fail safely when the configured proxy cannot support its transport instead of silently connecting directly.

Failing open undermines the privacy guarantee

The WebTransport behaviour highlights the broader question of what a browser should do when a feature cannot operate through the configured proxy. From a performance and compatibility perspective, opening a direct connection may appear helpful because the application continues working.

From a privacy perspective, this is a dangerous fail-open design. The browser satisfies the webpage’s request by discarding the network-routing expectation chosen by the user.

When a user enables Private Relay or configures a browser proxy, privacy should take precedence over transparent fallback. If the feature cannot use the protected path, the browser should block the connection, disable the feature or request explicit consent before revealing the direct network.

Silent bypass prevents the user from making an informed choice. The page continues functioning, while the privacy control appears active and the destination receives the information it was meant to conceal.

This principle applies beyond WebKit. Secure web gateways, anonymizing browsers and enterprise proxies must define how unsupported protocols are handled. Allowing direct fallback turns a compatibility feature into an escape route.

Corporate proxy policies may also be affected

Organizations often configure browser proxies or secure web gateways to inspect, control and log employee browsing. The WebKit bypasses may create concerns beyond personal IP privacy if selected requests evade the organization’s expected network path.

Direct DNS queries can bypass corporate resolution policies and expose browsing-related hostnames outside approved infrastructure. WebTransport connections may avoid controls designed primarily for proxied TCP traffic. WebAuthn validation requests could communicate with external destinations without appearing in the expected browser proxy logs.

The extent of enterprise impact depends on whether the device also uses network-layer firewalling, DNS enforcement, VPN tunnelling or endpoint controls. A browser-level proxy alone may not be sufficient to guarantee that every WebKit request passes through corporate security infrastructure.

Organizations should restrict direct outbound DNS and require devices to use approved resolvers. Firewalls can limit unauthorized UDP and QUIC communication, while managed VPN or zero-trust agents can route device traffic through controlled gateways.

Blocking QUIC globally may affect performance and legitimate applications, so policies should be evaluated carefully. The objective is not to disable every modern protocol but to ensure that new traffic types cannot bypass required monitoring and security controls.

All iOS browsers share platform-level exposure

Users sometimes respond to a browser security issue by installing another browser. On iOS and iPadOS, that strategy may provide limited value when the underlying weakness exists in WebKit or an operating-system service shared by all browsers.

Chrome, Firefox, Edge and Brave may offer different interfaces, synchronization services and privacy settings, but their webpage processing still depends heavily on Apple’s platform browser engine.

This concentration allows Apple to maintain consistent platform security controls, but it also means one WebKit issue can affect a broad range of applications simultaneously.

Organizations should therefore prioritize operating-system and WebKit updates rather than relying on browser substitution as the primary response. Managed device inventories should track the Apple platform version because WebKit fixes may arrive through system updates rather than independent browser releases.

Users should keep automatic security updates and Background Security Improvements enabled where available. Delaying an iOS or macOS update can leave several installed browsers exposed through the same underlying component.

The lack of an immediate patch requires measured guidance

At the time of disclosure, Apple had not publicly released a specific correction for the three reported proxy bypasses and said it was investigating the findings. This means users cannot yet resolve the issue simply by installing a named fixed version.

The absence of a patch does not mean every Safari session is automatically exposed. A website must deliberately invoke the affected functionality and correlate the resulting request with the visitor. There is also no public evidence that the technique has been used widely in malicious campaigns.

However, the attack is practical enough that users with strong privacy requirements should apply temporary protections rather than dismissing it as theoretical. A reputable device-level VPN can reduce exposure, and organizations can enforce network-layer routing and DNS controls.

Users should also install Apple updates promptly when a correction becomes available. Security teams should monitor Apple’s advisories and WebKit release notes rather than relying only on the original media report.

The issue should be discussed accurately. It is a privacy bypass and source-address disclosure, not remote code execution, credential theft or complete compromise of the Apple device. Exaggerating the impact would obscure the real architectural lesson.

Websites can misuse legitimate APIs for tracking

The disclosed methods reinforce that privacy abuse frequently occurs through standard web APIs rather than obvious malware. DNS prefetching, WebAuthn and WebTransport each have legitimate uses and do not need to be disabled permanently merely because they can expose routing inconsistencies.

The security problem arises when websites invoke these APIs for purposes unrelated to their intended function. A site claiming passkey support can trigger a related-origin request without actually requiring the user to authenticate. A site with no meaningful real-time communication requirement can open WebTransport solely to identify the direct IP address.

Browser permissions and privacy controls should evaluate externally observable network behaviour, not only access to local devices such as the camera or microphone. A background request revealing the user’s source address may deserve restrictions even though it does not access a conventional protected resource.

Web platforms have historically allowed many network requests without user prompts because constant authorization messages would make browsing unusable. The better solution is consistent enforcement of the selected routing and privacy policy rather than adding another warning users will eventually approve reflexively.

IP privacy remains only one layer

Even after the proxy bypasses are corrected, users relying on Private Relay or VPN services should remember that websites can identify and track visitors through other signals. Cookies, logged-in accounts, browser storage, screen characteristics, fonts, timezone, language and graphics data can contribute to a persistent browser fingerprint.

A hidden IP address reduces one important tracking signal, but it does not erase the rest of the browser profile. Conversely, an exposed IP address does not necessarily identify an individual without additional context.

Privacy protection therefore requires multiple layers, including tracker blocking, storage isolation, anti-fingerprinting controls and careful separation of browsing identities. Users cannot become anonymous merely by enabling one network feature and continuing to log into the same accounts everywhere.

Organizations protecting sensitive users should consider browsers and profiles designed for compartmentalization. Personal, privileged and investigative activity should not share the same cookies, accounts and browsing environment.

The broader cybersecurity lesson

The WebKit proxy bypasses demonstrate that privacy guarantees must be enforced consistently across the complete browser and operating-system networking stack. Protecting the main webpage request is insufficient when background DNS, authentication and transport features can create direct connections outside the configured proxy.

The issue is particularly significant for Apple because WebKit underpins Safari and third-party browsers across iOS and iPadOS. One routing inconsistency can therefore affect users across several applications, even when they believe they have selected a different browser.

Apple should ensure that DNS prefetching, WebAuthn Related Origin Requests and WebTransport honour the active proxy or Private Relay configuration. Where the protected path cannot support a request, WebKit should block or explicitly disclose the fallback rather than silently revealing the direct network.

Users with elevated privacy requirements should use a full-device VPN as an interim defence and should install the eventual Apple correction promptly. Enterprises should enforce DNS and outbound-routing policies at the device or network level rather than assuming that browser proxy settings capture every form of web communication.

The disclosure does not mean that iCloud Private Relay provides no value. Its dual-hop design continues to limit routine IP-based tracking for supported Safari traffic. The problem is that privacy protection is only as complete as the least compliant component participating in the browsing session.

A website should not be able to learn a user’s real IP merely by invoking a feature that happens to leave through another networking path. When a browser claims to use a privacy relay, every request initiated on behalf of the page must either use that relay or remain blocked.

Anything less turns the privacy control into a partial routing preference, and users reasonably expect something stronger than a suggestion when they are paying a subscription to hide their address.

Cybersecurity researchers have disclosed a security issue with Apple's iCloud Private Relay tool that can expose a user's real IP address. Introduced with iOS 15, iCloud Private Relay employs a dual-hop architecture to ensure users' privacy by routing their Safari web traffic through two relays so that no single third-party, including Apple, can determine where the request is originating from

Source: Apple iCloud Private Relay Can Expose Real IPs Through WebKit Proxy Bypasses via The Hacker News — published 06 Aug 2026.