Private Relay Has Three Side Doors: What Safari's IP Leaks Mean

You open Safari with iCloud Private Relay enabled. The page request crosses two relays, and the site sees a temporary address instead of the IP address assigned to your phone. Then a feature hidden inside that page asks WebKit to make a different kind of connection. That second request can leave directly from your device.

The main road has privacy protection. Three side doors do not.

On 4 August 2026, researchers Talal Haj Bakry and Tommy Mysk published tests showing that DNS prefetching, a passkey-related WebAuthn check, and WebTransport can bypass WebKit’s browser-level proxy configuration. The first path can expose the DNS service used by the device. The other two can expose its public IP address. Their tests also found the same paths outside Apple’s iCloud Private Relay. (Mysk)

The finding matters most to people who believed every connection triggered by a Safari page followed the relay. It also matters to iOS browsers that use WebKit’s proxy interface for Tor or another privacy network. It does not mean that every Safari visit has already revealed every user’s address, and it does not make a full-device VPN a perfect anonymity system. It shows something more precise: privacy protection applied at one software layer can miss traffic created by another.

As of 10 August 2026, Apple told 404 Media that it was investigating, according to The Hacker News. Apple had not provided that publication with a public fix timeline. (The Hacker News) The researchers have released a test page, and their Psylo browser has shipped mitigations. People with a serious need to hide their network location should treat the edge as open until Apple documents a fix.

What the researchers found

The investigation began with a user who saw DNS leaks on certain sites while using Psylo, a browser made by the same researchers. Psylo routes each browsing compartment through a proxy. A normal page request should therefore reach the destination from the proxy, while the user’s network stays behind it. The leak appeared only on some pages because a particular performance hint was triggering a lookup outside that route. (Mysk)

That first clue led to three paths. Each starts from an ordinary web feature. None requires malware on the phone. A site has to include or invoke the relevant feature, and the stronger IP-address tests described by Mysk can be triggered without the visitor clicking a passkey prompt or completing a login. The Hacker News reports that a site would need to exploit the behavior deliberately if it wanted to join the leaked address to the current browsing session. (The Hacker News)

The first path uses DNS prefetching. DNS is the lookup that turns a name such as example.com into a network address. Browsers can perform that lookup before you click a link so the later connection starts faster. Mysk found that WebKit could send these speculative lookups through the device’s normal DNS route rather than the proxy configured for the browser. A site can place a unique hostname in the prefetch hint and watch for the query at the authoritative DNS server it controls. (Mysk)

The leak here needs careful wording. A DNS query can reveal the resolver and network path used by the device. Depending on the network setup, the server that ultimately receives the authoritative query may see an address belonging to the user’s resolver rather than the user’s own public address. That is still useful metadata. A unique query can show that a visitor’s supposedly relayed session caused activity through a particular real-world DNS path. Mysk dates support for this behavior on iOS to iOS 26.0, released in September 2025.

The second path uses WebAuthn Related Origin Requests. WebAuthn is the browser standard behind passkeys. A passkey normally belongs to one site name, but a company with several related domains may want one credential to work across them. Before allowing that relationship, the system fetches a small file from the requested domain to check which origins are authorised to share it.

WebKit hands that check to the operating system’s credential service. According to the researchers, the service fetches the validation file directly because it does not inherit the proxy selected by the browser. A site can ask for a related-origin check against a host it controls and observe the source address. Mysk says conditional mediation can trigger the fetch without showing a passkey interface or asking the visitor to touch anything. The feature has been active since iOS 18.0, released in September 2024. (Mysk)

The third path uses WebTransport, a web interface for low-latency connections over HTTP/3 and QUIC. WebTransport is useful for applications that need several streams or time-sensitive messages without treating every piece of data like a conventional page load. In the tested WebKit path, the connection received its own network parameters and did not receive the browser session’s proxy. The server saw the device’s public address. Mysk traces public iOS support to iOS 26.4 in March 2026. (Mysk)

Three features, one architectural mistake. The browser displays a page through the protected route, yet helper work related to that page is delegated to code that has a direct path. The visual session and the network session stop meaning the same thing.

Mysk tested the behaviors against iCloud Private Relay and against WebKit browsers using Apple’s application-level proxy configuration. The researchers also contacted the Tor Project and the developers of Onion Browser. Their report says Onion Browser’s Silver security level disables WebTransport through Lockdown Mode, which closes that one route. It does not claim that the setting closes the DNS-prefetch and WebAuthn paths.

The researchers published a proof-of-concept page at leaks.psylo.app. A test page can help a user or developer confirm current behavior, but it is also a page designed to learn whether direct connections are possible. Anyone with a sensitive network location should avoid casual self-testing from that location. A controlled lab, a disposable connection, or vendor documentation is safer than announcing your real path to a diagnostic site you have not independently inspected.

Why Private Relay can miss a request from Safari

Apple describes Private Relay as a two-hop system for Safari browsing. The network provider and Apple’s first relay can see the user’s IP address, while DNS records are encrypted. A second relay run by a third-party provider receives the destination name and creates a temporary IP address for the connection. Apple says this design prevents any one party, including Apple, from seeing both who the user is and which sites they visit. (Apple Support)

The separation is useful. The first relay knows where the connection came from but should not know the final site. The second relay knows the site but should receive the user through the first relay. The destination sees the temporary address. For ordinary Safari browsing, that can reduce what an internet provider and a website can join together.

The protection has always had a stated scope. Apple’s support page says Private Relay helps protect Safari browsing. It does not claim to carry every packet from every application on the device. Mail, third-party apps, voice calls, and arbitrary background traffic live outside that plain-language promise unless another Apple feature or network rule covers them.

The new research finds seams inside the Safari session itself. A page load uses one route. The operating system’s credential service performs a related-origin fetch through another. WebTransport creates a connection through another WebKit path. A speculative DNS lookup can escape through the normal resolver. To the person holding the phone, all of it began with one page in Safari. To the network stack, several components made separate decisions.

That difference is the mechanism behind the leak. Private Relay does not inspect and recapture every outbound connection after the fact. It protects traffic that enters its route. A connection born outside that route keeps the device’s ordinary network identity.

Picture a building with a screened front entrance. Visitors who use that door leave their names at reception and follow the access rules. A service corridor opens onto the street, and a delivery team has its own key. The front desk can perform perfectly while someone walks out through the corridor. Fixing reception will not help; the building needs to know every door that crosses the boundary.

Browser architecture has many service corridors. Name resolution may happen before a connection. Authentication can leave the rendering engine and enter an operating-system credential service. New transport protocols can use specialised networking code. Media, extensions, push messages, local-network discovery, and downloads may take paths that differ from the main document request. Every delegation needs the same privacy context or a firm refusal to proceed.

This is why the phrase “Safari traffic” needs a testable definition. Does it mean the HTML document and its usual subresources? Does it cover every network action caused by script running in the page? Does it include work sent to system services? Does it include future protocols added to WebKit after the relay shipped? A privacy claim survives only when engineers keep answering those questions as the platform changes.

The dates in Mysk’s report reveal another part of the problem. Related-origin support arrived in September 2024. DNS prefetching changed on iOS in September 2025. WebTransport arrived publicly in March 2026. A boundary that held for yesterday’s feature set can open when a new connection mechanism ships. Privacy testing has to follow capability growth, release after release.

What an IP address leak gives the site

An IP address is often described as if it were a home address printed on every packet. That metaphor helps until it becomes too literal. Many households share one public address across several devices. Mobile networks may put many subscribers behind carrier-grade translation. Addresses can change. A VPN address belongs to the provider. An office address may represent hundreds of people.

Even with those limits, a real public IP address can carry value. It usually points to an internet provider and a rough geographic area. It can distinguish a home connection from the relay address shown during the protected page load. A site can compare it with addresses seen during earlier visits, account logins, app sessions, advertising traffic, abuse reports, or data bought elsewhere. The address becomes more revealing when joined to time, cookies, browser characteristics, and an account.

The join is the important part. Suppose a journalist visits a sensitive site through Private Relay. The site sees a temporary relay address for the page. A WebAuthn-related request then arrives from the journalist’s normal connection with a unique token in the requested host. The operator can place both events within the same second and attach the real network to the relayed session. The temporary address did its job on the main request, but the second path supplied the missing link.

A hostile site does not need to turn an address into a person’s legal name on its own. It may only need to separate one visitor from the crowd. A company account could already carry a name. A domestic internet provider may later receive a legal demand tied to an address and time. An organisation watching both ends of a connection can use timing. A doxxer may compare the network with a stream, game server, or email header gathered elsewhere.

DNS leakage is different but can still narrow the picture. A direct lookup may reveal the resolver selected by the user’s network or device. A unique hostname proves that a particular browser event produced a query outside the expected proxy. When the resolver is local to an internet provider or organisation, that observation can supply location or affiliation clues. Encrypted DNS protects the query on part of its journey, yet the authoritative server must still receive enough information to answer the requested name.

The threat depends on who wants the information. A shopping site may use an address for fraud scoring or regional content. An advertising system may use it as one more correlation signal. A stalker running a link trap may want a rough city and a stable household connection. A state investigator may combine precise timing with records held by a provider. The same leak ranges from annoying to dangerous because the adversary changes.

For most people, Private Relay still removes useful browsing metadata from routine paths. A single side channel does not place an investigator behind every web page. But a person using the feature to protect a source meeting, hide a clinic visit, separate an activist identity, or avoid a local censor cannot average the risk across ordinary traffic. One deliberate page can be enough.

This is the practical split. Casual privacy benefits tolerate some residual exposure while a fix is pending. High-stakes anonymity cannot assume the side doors will remain unused simply because most sites have no reason to touch them.

Who should change course now

A useful response starts with the reader’s threat model. Someone who enables Private Relay to reduce profiling on everyday Safari visits has a different problem from someone whose safety depends on preventing a website from learning the network they are using. Giving both people the same instruction would waste one person’s effort and understate the other’s risk.

For an ordinary iCloud+ user, keep Private Relay enabled if it fits your browsing. The research does not show that turning it off improves privacy. A protected main route remains better than sending that same route directly. Keep iOS, iPadOS, macOS, and Safari current, then watch Apple’s security notes for a documented change to these paths. Avoid assuming that the current relay icon promises device-wide coverage.

A VPN operating at the device’s network layer is not affected by these three proxy-bypass mechanisms, according to Mysk, Privacy Guides, and Malwarebytes. The direct WebTransport or WebAuthn request still enters the system’s VPN tunnel because the tunnel sits below the browser and credential service. That is a meaningful mitigation for this specific leak. (Privacy Guides, Malwarebytes)

A VPN changes who can observe the traffic. The website sees the VPN exit address, while the VPN provider receives the user’s connection and can observe metadata that Private Relay divides between two operators. Account logins, cookies, browser fingerprints, and personal behavior can still identify the user. A VPN closes these three direct network paths; it does not supply anonymity by itself.

People using an iOS Tor browser face a harder constraint. Apple’s platform has historically required iOS browsers to use WebKit, and the browsers covered by the research rely on WebKit’s proxy configuration. A Tor circuit can be sound while a separate WebKit request travels beside it. Privacy Guides states that the issue affects Onion Browser and other proxy browsers built on the same path. (Privacy Guides)

If revealing the source network could expose a protected identity, move that session away from the affected architecture. Tor Browser on a supported desktop platform routes browser traffic through Tor under a design maintained for that purpose. Tails adds an operating system that sends its network traffic through Tor and blocks ordinary direct networking. Those tools still have limits, especially account correlation, endpoint compromise, document metadata, and behavior that links two identities. They remove the specific assumption that an iOS WebKit proxy will catch every page-triggered connection.

Psylo users have a vendor mitigation now. Version 1.3.1 blocks DNS-prefetch hints and disables WebTransport and WebAuthn by default, with per-compartment switches for sites that genuinely need those features. That is a clear trade: some logins or web applications may stop working until the user grants the capability. (Mysk)

Onion Browser users at the Silver level receive protection from the WebTransport path because Lockdown Mode disables that feature, according to Mysk. The report does not give that setting credit for the other two paths. Treating a partial mitigation as a complete fix would recreate the original mistake: a protected route would stand in for the whole system.

Developers who ship a WebKit proxy browser should assume the framework’s proxy property is incomplete until testing proves otherwise. Block or gate features that can create direct connections, build tests around unique controlled hostnames, and repeat those tests when Apple adds a transport or authentication feature. A browser that cannot guarantee the route should say so before a user places a sensitive identity behind it.

A concrete response for different stakes

The findings are technical, but the action can stay simple. Decide first how much harm a revealed network could cause. Then choose the smallest response that holds against that harm.

1. Keep routine protection switched on. If you use Private Relay to reduce ordinary tracking, leave it enabled. Install current Apple updates and do not treat the feature as a full-device tunnel. The main Safari path still receives protection while the side paths await a platform fix.

2. Use a trusted full-device VPN for the three named leaks. This is appropriate when you need the site to see a VPN address rather than your home, office, or mobile address. Confirm that the VPN is active before opening the site. Remember that the provider becomes a party to your traffic and that logging into a personal account can identify you anyway.

3. Move high-stakes anonymous browsing off the affected iOS path. If a source, protest role, investigation, or protected identity depends on hiding the originating network, use a platform where Tor Browser can control its network stack, or use Tails for stronger routing discipline. Keep personal accounts and ordinary browsing out of that session.

4. Do not use a public leak test from a sensitive location without a plan. The test works by receiving traffic and comparing paths. Run it in a lab, through a disposable connection, or after the vendor has documented what it records. Curiosity is a poor reason to send a unique diagnostic request from a protected network.

5. Record the exact promise your organisation makes. If you manage journalists, researchers, executives, or at-risk communities, change “Private Relay hides your address” to a dated statement with scope: as of August 2026, ordinary Safari requests may use the relay, while three documented WebKit features can bypass it. Advice becomes safer when its edge is visible.

6. Test direct paths in managed apps. Browser and privacy-app teams should cover DNS prefetch, WebAuthn related origins, and WebTransport in regression tests. Observe traffic at the destination and on the device. A green page load through the proxy proves only that page load.

7. Watch for an Apple fix before relaxing the workaround. Look for release notes or a WebKit change that addresses all three mechanisms. A patch to WebTransport alone leaves two routes. Retest the current operating-system release, because the relevant behaviors arrived in different versions and may be repaired separately.

This sequence gives ordinary users permission to stop after updates and clear expectations. People facing a real identification threat need the heavier step. Security advice earns trust when it distinguishes those lives instead of turning everyone into a full-time operator.

What browser and platform teams should learn

The bug class will outlive these three WebKit features. Any privacy system that marks traffic at one layer can lose that mark when work crosses into another service, process, or protocol. The engineering task is to carry policy with causality: this connection exists because this protected page asked for it, so it must inherit the page’s route.

Inheritance should be explicit. A WebAuthn credential service receiving a related-origin request needs more than a URL. It needs the network privacy context of the browser session that caused the request. If the service cannot honour that context, the platform can deny the operation, ask for user approval, or return an error that the browser can explain. Sending directly is the dangerous default because success hides the privacy failure.

New protocols need boundary review before release. WebTransport was enabled after Private Relay already existed. A release test should have created a page behind the relay, opened a controlled WebTransport endpoint, and asserted that the endpoint saw the relay address. The same pattern applies to future peer-to-peer APIs, authentication helpers, local-network features, and system-mediated fetches.

Teams also need negative tests. A normal integration test proves that a passkey works across related domains. A privacy test proves that the validation request cannot escape the selected route. A performance test proves that DNS prefetch makes a later navigation faster. A privacy test proves that the prefetch does not disclose a different network path. Features pass only when both properties hold.

Interface design should name the sacrifice. Psylo’s mitigation disables WebAuthn and WebTransport by default, then lets a user re-enable them for a compartment. That may be too much control for a general browser, but the principle is sound. If a site requires a feature that weakens the selected network isolation, the browser should refuse silently unsafe success. A clear prompt can say that enabling the feature may reveal the current network address.

Platform owners can do better than pushing the choice onto users. Apple controls WebKit, the credential service, Private Relay, and the operating-system network stack. It can give delegated services a supported way to inherit the relay context. It can make the proxy rule apply to every connection caused by a protected web session. It can add conformance tests so the next networking feature cannot ship around that rule.

Documentation needs the same precision. Apple’s support page accurately limits Private Relay to Safari browsing, but users reasonably understand a connection initiated by a Safari page as part of browsing. A service boundary invisible to the user should not quietly narrow the promise. Until the implementation changes, support material should name the affected features and explain the mitigation.

The disclosure process also deserves a factual note. Privacy Guides says the researchers released the findings publicly rather than first filing them privately with Apple, citing long response times and earlier rejected reports. Malwarebytes later wrote that the researchers had reported the problems to Apple and expected patches by fall. The Hacker News says Apple told 404 Media it was investigating the report. These accounts describe different moments or use “reported” differently, and the public sources do not resolve the sequence cleanly. (Privacy Guides, Malwarebytes, The Hacker News)

The operational fact is clear enough for users: Apple knows about the public research and was investigating as of the reporting available on 10 August 2026. No source reviewed for this article provides a released Apple fix covering all three paths.

The edge of a privacy tool is part of the tool

Private Relay’s two-hop design answers a valuable question: how can Safari keep one operator from seeing both the user’s network identity and the destination? The new findings answer a second question: which requests count as Safari traffic when a page activates services beyond the ordinary loader?

A privacy tool must answer both. Strong cryptography and careful relay separation cannot protect a request that never enters the system. The failure sits at the boundary, where a page hands work to a resolver, credential service, or transport implementation and the privacy context falls away.

This pattern appears far beyond Apple. A messaging app can encrypt text while a cloud backup stores a readable copy. A browser can isolate cookies while a shared identifier joins accounts elsewhere. Tor can protect the network route while a document opened outside the browser calls home. A secure main path makes side paths more important because users place more trust behind it.

The Anonymity Playbook uses a practical standard for tools like these: name the edge where protection stops, then decide whether that edge fits your adversary. Private Relay still has value for routine Safari privacy. As of August 2026, it has three documented edges that a deliberate site can reach. Ordinary users can keep the benefit and update. People protecting a sensitive identity should route around the affected design.

You cannot manage a boundary you cannot see. The researchers made this one visible. Apple now needs to carry the relay context through every page-triggered connection or block the connection that cannot carry it. Browser teams need tests that watch the side doors, not only the front gate.

Until then, use Private Relay for the job it can do. Use a trusted device-level tunnel when these three direct paths matter. Use a Tor-native desktop setup or Tails when revealing the originating network would carry serious consequences. Keep accounts, behavior, and device compromise in the threat model, because a clean IP address is one piece of anonymity rather than the whole.

That response is less dramatic than abandoning Safari and more honest than trusting an icon. It gives each reader a decision matched to the cost of being identified.

If you want practical privacy and security analysis without the daily alarm cycle, subscribe on this site. One email per month.

Sources

• Mysk: IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay, accessed 2026-08-10
• The Hacker News: Apple iCloud Private Relay Can Expose Real IPs Through WebKit Proxy Bypasses, accessed 2026-08-10
• Privacy Guides: Apple’s Private Relay Leaks Your Real IP Address in Safari, accessed 2026-08-10
• Malwarebytes: Apple WebKit vulnerabilities reveal your IP address, despite Private Relay, accessed 2026-08-10
• Apple Support: About iCloud Private Relay, accessed 2026-08-10