iCloud Private Relay Is Leaking Real IP Addresses. Here Is How the Bypass Works

In August 2026, security researchers Talal Haj Bakry and Tommy Mysk disclosed a set of flaws in WebKit — the browser engine behind Safari and every browser on iOS — that allow websites to see your real IP address even when Apple's iCloud Private Relay is switched on.

This matters because Private Relay's entire promise is that no one, including Apple, can connect who you are to what you browse. The bypass breaks that promise quietly: no warning, no error, no user interaction. Your device simply sends some traffic outside the protected path, and any website that wants to can collect it.

We are a VPN company, so you should read our take on an Apple privacy feature with appropriate skepticism. We will try to earn your trust the same way we always do: by describing the issue accurately, including the parts that are inconvenient for VPN marketing.

What iCloud Private Relay promises

Apple introduced Private Relay with iOS 15 in 2021 as part of the paid iCloud+ subscription. The design is genuinely good. Your Safari traffic is routed through two separate relays:

• — The first relay, operated by Apple, sees your real IP address but not the websites you visit.
• — The second relay, operated by a third-party partner, sees the websites you visit but not your real IP address.

The result is that no single party holds both halves of the picture. It is a dual-hop architecture, and on paper it offers a meaningful privacy property that even a conventional single-hop VPN does not: you do not have to trust any one company with the complete pairing of identity and activity.

That is the design. The problem the researchers found is that WebKit does not consistently send traffic through it.

The three features that bypass the proxy

According to the researchers, three WebKit features ignore the configured proxy path and connect directly from the device, revealing the network you are actually on:

• — DNS prefetching. To speed up browsing, WebKit resolves hostnames on a page before you click them. Those lookups go through the device's normal DNS path — not through the proxy. Your resolver, and whoever operates it, sees them coming from your real network.
• — WebAuthn Related Origin Requests. WebAuthn is the web standard behind passkeys. When a site uses a feature called Related Origin Requests, the operating system's credential service fetches a validation file from that site — and it does so directly from the device, outside the proxy.
• — WebTransport. This newer API opens a direct HTTP/3 connection between the browser and a server. In WebKit, that connection simply does not go through the configured proxy.

In each case the mechanism is different, but the outcome is identical: a request leaves your device on your real network connection, carrying your real IP address, while the Private Relay indicator suggests you are protected.

Why the WebAuthn leak is the serious one

DNS prefetching leaks are bad but partial — they expose lookups, not a clean identifier tied to your session. The WebAuthn variant is worse, and it is worth understanding why.

Any website can configure WebAuthn in a way that triggers the leak. You do not need to use a passkey. You do not need to click anything. The site does not need to be a service you have an account with. As Mysk put it to The Hacker News, a website has to deliberately exploit the behavior to associate your browsing session with the leaked IP address — but once it does, the association requires no interaction from you at all.

A privacy feature that fails silently is more dangerous than no privacy feature at all, because it changes what you are willing to do while believing you are protected.

This is the same reason we are hard on VPN kill switches and leak protection in our own industry. The failure mode that matters is never the honest disconnect — it is the quiet one.

The scope: every browser on your iPhone

On iOS and iPadOS, Apple requires every browser to use WebKit as its engine. Chrome, Edge, Firefox, and Brave on an iPhone are all WebKit underneath the interface. That means these leaks are not a Safari problem — they are a platform problem. Switching browsers on an iPhone does not switch engines, so it does not avoid the bypass.

The issues also affect macOS, along with any WebKit-based browser that relies on WebKit's proxy configuration APIs. Notably, the researchers point out that not every browser everywhere is affected — desktop Chrome, which uses its own engine and its own network stack, is not.

We covered this single-engine constraint in our iPhone privacy guide: on Apple's mobile platforms, the privacy properties of "your browser" are really the privacy properties of WebKit, whichever icon you tap.

How to check your own device

The researchers published a proof-of-concept page at leaks.psylo.app where you can see the behavior yourself. It shows two things side by side: the regular HTTPS traffic WebKit generates through the protected path, and the "possible IP leaks" — requests that escape the proxy and carry your real address.

"Possible" is the researchers' word, chosen carefully, because the outcome depends on your setup. Some browsers are unaffected, and — their finding, not our marketing — the leaks are mitigated when the device is connected to a VPN.

Why a VPN is not affected by this class of bug

This is the part where a VPN company would normally declare victory. We will make the accurate claim instead, because the accurate claim is interesting on its own.

Private Relay and browser proxy configurations operate at the application layer. The browser, or the OS on the browser's behalf, decides which requests go through the protected path. Every feature that makes its own connection — a prefetcher, a credential service, a new transport API — is a chance for that decision to be made wrong. That is exactly what happened here, three separate times.

A VPN operates at the network interface level. The tunnel captures traffic from the whole device before it leaves, regardless of which app or API generated it. A WebKit feature that skips the browser's proxy still ends up inside the tunnel, because the tunnel does not ask WebKit's permission. That is why the researchers note these leaks are mitigated under a VPN — it is a structural property, not a product feature.

Two honest caveats, because our whole brand is that we include them:

• — VPNs have had their own leak classes. WebRTC leaks, IPv6 leaks, and DNS leaks outside the tunnel have all been real problems in our industry. The lesson of this story is not "VPNs are immune" — it is that every privacy layer needs adversarial testing, ours included.
• — A VPN concentrates trust; Private Relay splits it. When you use a VPN, one company could theoretically see both your identity and your destinations. Private Relay's dual-hop design avoids that — when it works. Which layer is right for you depends on your actual threat model, and for some people the answer is both.

A pattern, not an isolated incident

This is not the first hole in Private Relay. Shortly after the feature launched in 2021, researchers at FingerprintJS demonstrated a WebRTC-based mechanism that leaked users' real IP addresses. And just over a month before this disclosure, Apple fixed a vulnerability in Hide My Email — the companion iCloud+ feature — that allowed users' real email addresses to be unmasked under certain conditions.

Apple did not immediately respond to the researchers' disclosure, but told 404 Media that it is investigating the report. Based on Apple's history with the 2021 WebRTC issue, a fix is likely. The interval between disclosure and fix is the window that matters for anyone relying on the feature today.

What to actually do

• — Recalibrate what Private Relay covers. It protects Safari traffic through Apple's relays — except when WebKit features bypass it. Until Apple ships a fix, treat the IP-hiding guarantee as unreliable against a website that is actively trying.
• — Test your own setup. The proof-of-concept page shows you, in your own browser, whether your real address escapes. Evidence beats marketing — ours and Apple's alike.
• — Install updates when the fix lands. WebKit fixes ship with OS updates on Apple platforms. This is one more reason not to sit on them.
• — If hiding your IP address is a real requirement for you — not a nice-to-have — use a tool that operates at the network layer, and hold its provider to the standard in our trust checklist. That standard applies to us too.

The broader lesson is one we keep returning to on this blog: privacy guarantees are only as good as their weakest bypass, and the weakest bypass is usually a feature nobody was thinking about. Apple's dual-hop design was not defeated by broken encryption. It was defeated by a prefetcher, a login convenience, and a new transport API — each doing exactly what it was built to do.

Sources

• — Talal Haj Bakry and Tommy Mysk — original research (Mysk)
• — Proof-of-concept leak test page (leaks.psylo.app)
• — The Hacker News — "Apple iCloud Private Relay Can Expose Real IPs Through WebKit Proxy Bypasses" (August 6, 2026)
• — FingerprintJS — iCloud Private Relay WebRTC leak (2021)