iCloud Private Relay Is Leaking Your Real IP Address

Researchers found three WebKit features that bypass iCloud Private Relay and expose your real IP and DNS resolvers. How each leak works, how to test your iPhone, and why turning Private Relay off does not help.

By Tudor Uzun

Founder and Senior Software Engineer, IP Trackers

Published August 7, 2026Editorial standards

On August 4, 2026, security researchers Talal Haj Bakry and Tommy Mysk published evidence that three WebKit features route around iCloud Private Relay and expose the real IP address and DNS resolvers of the device using it. The leaks are not a flaw in Apple's relay servers. They are a consequence of where the protection sits: Private Relay operates inside the browser layer, and all three features make their network requests somewhere the browser layer cannot reach. 404 Media reproduced the result against a live proof of concept. Apple has said it is investigating and has given no timeline for a fix.

What the researchers actually found

The finding is narrower and more interesting than the headlines suggest. Nobody broke Apple's encryption, compromised a relay operator, or deanonymized the two-hop design. The relay does what it claims for the traffic it handles. The problem is that three specific web platform features cause a request to originate somewhere other than the browser engine, and a proxy configured on the browser engine has no authority over a request it never sees.

A web page you visit can trigger all three deliberately. None of them require you to click anything, grant a permission, or notice that anything happened. From the page's perspective, it embeds an ordinary-looking element or calls an ordinary-looking API, and a connection arrives at a server it controls carrying your real address.

Read the third column carefully, because it is the part that received the least attention. The WebAuthn bypass has been present since iOS 18.0 in September 2024. This is not a bug introduced last quarter and caught quickly. It is a gap that existed for nearly two years across every version of iOS in that window, affecting a feature people pay for specifically to hide the thing it exposed.

Why this is not an ordinary leak

The word "leak" gets used loosely in privacy coverage, and it usually describes one of two things. Either a tunnel dropped and traffic fell back to the normal route, or a browser feature such as WebRTC volunteered an address the tunnel never controlled. Both are well understood, both are testable, and both are the reason tools like our WebRTC leak test and DNS leak test exist.

This is a third category. The protection is working, the connection is up, nothing has failed, and the address escapes anyway because a different part of the operating system made the request. There is no error state to detect, no disconnection to notice, and no indicator in the interface that anything is wrong. Private Relay reports itself as active the entire time, and it is active. It simply was not consulted.

Do you even have Private Relay turned on?

Before worrying about a bypass, it is worth confirming that you were using the feature at all. A surprising share of people who believe they are covered are not, for reasons that have nothing to do with this research.

Private Relay requires a paid iCloud+ subscription. Any storage plan above the free tier includes it, but the free 5 GB tier does not. It is tied to your Apple Account rather than to a device, so enabling it once applies across everything signed into the same account, and it can be switched off per network in your Wi-Fi settings without any obvious indication elsewhere.

It is also unavailable in a number of countries for regulatory reasons, and some mobile carriers and corporate networks block it deliberately because it prevents them from inspecting or filtering browsing traffic. When that happens, iOS will typically prompt you once and then quietly run without it. Months later, most people do not remember the prompt.

Check Settings, then your name, then iCloud, then Private Relay. If the toggle is off, or if it reports that your network is not compatible, none of this research applies to you, because you were presenting your real address the whole time. That is worth knowing on its own.

Leak one: DNS prefetching

DNS prefetching is a performance feature. A page tells the browser "I am probably going to load something from this hostname shortly" using a link hint, and the browser resolves that hostname early so the lookup is already done when the resource is requested. It shaves latency and has been part of the web platform for years.

The researchers demonstrated that when WebKit acts on one of these hints, it resolves the hostname through the device's standard DNS resolver rather than through the configured proxy. If the hostname is one the page author controls, the authoritative nameserver for that domain observes the query arriving from your actual network. The page does not need a response, a rendered resource, or any user action. It needs one hint element and a nameserver it owns.

What escapes here is your DNS resolver and, through it, a strong signal about your real network. Private Relay ordinarily proxies Safari's DNS lookups precisely so this cannot happen. Prefetch hints step outside that path. If you want to understand why resolver identity is so revealing on its own, our explainer on how DNS works covers what a resolver can infer about you before a single page loads.

Leak two: WebAuthn related origin requests

This is the most serious of the three, and the mechanism is worth following closely because it explains why the other two are structural rather than accidental.

WebAuthn is the standard behind passkeys. It supports a feature called related origin requests, which lets one company use a single passkey across several domains it owns. To confirm that a claimed relationship is genuine, the platform fetches a well-known file from the claimed domain and checks that the two sides agree.

On Apple platforms, that fetch is not performed by WebKit. It is performed by the operating system's credential service, which issues its own HTTPS request directly from the device and knows nothing about any proxy the browser configured. A page can name any host it likes in the request, and the fetch fires without waiting for user interaction. So a page can silently cause your device to make a direct, unproxied HTTPS connection to a server of the attacker's choosing, carrying your real public IP address.

That is the whole attack. It requires no vulnerability in the cryptography, no user error, and no interaction. It works because responsibility for the request sits in a process that never received the privacy setting.

Leak three: WebTransport

WebTransport is a newer API for low-latency two-way communication over HTTP/3, aimed at applications like games, live media, and realtime collaboration. It arrived on iOS in version 26.4 in March 2026.

Constructing a WebTransport object opens a QUIC connection, and the researchers found that this connection is established without the proxy configuration being applied to the underlying network session. The connection goes out directly. As with the other two, a page can do this on load, and the destination server sees the device's real address.

This one has the cleanest mitigation of the three, because a browser can simply refuse to offer the API. Onion Browser's Silver security level disables WebTransport outright, and the Psylo browser disabled it by default in version 1.3.1 alongside blocking prefetch hints and turning off WebAuthn.

What Private Relay was designed to do

To judge how badly this undermines the feature, it helps to be precise about what Apple promised, because Private Relay has always been narrower than most subscribers assume.

Private Relay is bundled with iCloud+ and covers Safari browsing plus a limited set of DNS lookups. It sends traffic through two hops. The first is operated by Apple, which can see your IP address but not the destination you requested. The second is operated by a partner content delivery network, which can see the destination but receives only a coarse location rather than your address. The design goal is that no single party holds both halves of the pair.

It was never a VPN. It does not cover other apps, it does not cover non-Safari traffic, and Apple has always documented it this way. But the one thing it was unambiguously supposed to do, for the traffic it covers, is prevent the sites you visit in Safari from learning your real IP address. That is the promise these three bypasses break.

Why the architecture allowed this

The root cause is the difference between protecting an application and protecting a device. A proxy configured on a browser engine can only govern requests that engine originates. The moment a request comes from the operating system, another framework, or a network API that skips the engine's session configuration, the proxy is not bypassed so much as simply absent.

The first row is the story. Everything in the second column of that row is genuinely protected, and everything in the third column always was outside the boundary. What the research showed is that the third column contains more than anyone realized, and that ordinary web pages can reach into it on demand.

This is the same distinction we draw in our comparison of proxies versus VPNs, and it is not an academic one. It is the difference between a setting that governs one program and a tunnel that governs the network interface.

Who is affected

The blast radius is wider than iCloud+ subscribers, because the flaw is in the engine rather than in the relay.

The row that surprises people is Chrome and Firefox on iOS. Apple requires every browser distributed on iOS to render with WebKit, so a browser's own engine protections do not apply on that platform. A Firefox user on a desktop and a Firefox user on an iPhone are running substantially different software, and only one of them is running Gecko.

The bitter detail is that the privacy-focused proxy browsers were hit hardest in relative terms. They exist to route everything through Tor or a per-tab proxy, so a bypass in the layer beneath them defeats their entire purpose. Their users had the strongest expectation of protection and the same exposure.

Why some sites block Private Relay outright

There is an irony running underneath this story. While researchers were demonstrating that Private Relay leaks too much, a large number of websites have spent years treating it as though it hides too much.

Banks, ticketing platforms, streaming services, and fraud-scoring systems frequently block or challenge traffic arriving from relay egress ranges. From their side the logic is understandable: the address does not correspond to a residential connection, the coarse location does not match the account's history, and the same egress serves an enormous number of unrelated users. That profile looks like a proxy, because in a technical sense it is one.

The practical result is that Private Relay users regularly hit verification loops, region errors, and outright refusals on sites that work fine the moment the feature is disabled. If you have ever wondered why a specific site insists you are somewhere you are not, our proxy and VPN detection check shows you what those systems see when they look at your address, and our guide to how modern VPN detection works explains the signals behind the decision.

So the same subscribers now learning that their address can escape the relay have also been penalized for years on the assumption that it never does. Both things are true at once, which is an uncomfortable place for a privacy feature to sit.

What an attacker actually gains

It is worth being accurate about the consequences rather than inflating them, because overstating this makes it harder to reason about what to do.

A site exploiting these bypasses learns your real public IP address, and in the prefetch case your DNS resolvers. From an address, the practical inferences are your approximate location, usually at city or regional accuracy, your internet provider, and the autonomous system your connection belongs to. It also gives a stable identifier that links sessions together across time, which is the point for a tracker: it defeats the separation Private Relay was providing between what you browse and who you are.

The identifier point is the one that matters most and gets the least attention. Private Relay's value was never that a single page view was anonymous; it was that the address a site recorded on Monday could not be matched to the address it recorded on Friday. A real address restores that link, and it also restores everything derivable from it. You can see the full picture yourself with our ASN lookup, which resolves an address to the network that operates it, or by reading how IP geolocation actually works to understand how precise the location inference genuinely is.

What it does not give anyone is your name, your street address, your device contents, or any account credential. An IP address is a network location, not an identity. We covered the realistic limits of what an address discloses in what someone can actually do with your IP address, and nothing about this research changes those limits. The severity here is that a paid privacy feature failed at its stated job, not that the exposed data is catastrophic on its own.

Why the two-year window matters more than the leak

If you take one thing from this research, make it the WebAuthn date rather than the leak itself.

A bypass that has existed since September 2024 has been available to any site that knew about it for the entire period. There is no way to determine retroactively whether it was used, by whom, or how widely, because a direct HTTPS request to an attacker-controlled host is indistinguishable from ordinary traffic in any log you have access to. The honest position is that the exposure window is known and the exploitation history is not.

That should temper how much confidence anyone places in privacy features that cannot be independently verified from outside. Private Relay gives you no way to confirm what it covered, and users had no signal that a gap existed for two years. A protection you cannot audit is a protection you are taking on trust.

How to test your own device

You can establish where you stand in a few minutes. The point of this sequence is to separate three different questions that people routinely collapse into one: what address are you presenting, is your relay active at all, and does traffic escape it.

Step one. Open Safari on the device in question and load our homepage IP check. Write down the address and the location it reports.

Step two.Open Settings, tap your name, tap iCloud, then Private Relay, and confirm whether it is switched on. If it is on, the address from step one should belong to one of Apple's relay partners rather than to your home provider.

Step three. Run our proxy and VPN detection check. It inspects the network the address belongs to. When Private Relay is working, the result should identify a relay or hosting network rather than a residential one.

Step four. Run the DNS leak test. This is the one that speaks directly to the prefetch bypass. If the resolvers reported belong to your own internet provider while Private Relay is on, DNS is taking a path the relay is not covering.

Step five. Toggle Private Relay off, reload the homepage check, and compare. If the address does not change at all, the relay was never covering that traffic in the first place, which is its own finding.

The researchers also published a proof-of-concept page that triggers the specific bypasses directly. Testing against a demo written by the people who found the flaw is the most direct confirmation available, and our tools are the right way to establish your normal baseline before and after.

Reading your results correctly

Two outcomes get misread constantly, and both send people to the wrong conclusion.

The first is a location that looks wrong. Private Relay deliberately gives the second hop only a coarse location, so a correctly functioning relay usually places you in the right country and the wrong city. That is the feature behaving exactly as designed. A wrong city is not evidence of a leak, and our guide to why IP location is often wrong covers the many ordinary reasons this happens.

The second is an address that never changes when you toggle the relay. People read that as a leak, but the usual explanation is that Private Relay was not covering that traffic to begin with, either because you were not in Safari or because the network you are on blocks the relay. Some corporate and school networks do this deliberately.

A genuine instance of this specific research looks different from both: the relay is on, your Safari address is correctly masked, and a page nonetheless receives your real address through a channel the relay never touched. That is not visible in a standard address check, which is precisely what makes it serious.

Should you turn Private Relay off?

No, and this is the most common wrong reaction to a story like this.

Turning the feature off does not close any of the three bypasses. They are direct requests that were never going through the relay, so removing the relay changes nothing about them. What it does change is everything the relay was correctly protecting, which is the large majority of your Safari traffic. You would be trading real coverage for zero improvement.

The rational response is either to accept a known and now-public gap in a feature that still helps, or to move to a protection layer that sits below the browser. The second option is the only one that actually addresses the finding.

Private Relay compared with a real VPN

This research is the clearest practical illustration of a difference that usually stays theoretical.

A VPN app on iOS establishes a system-level tunnel. Every packet leaving the device goes through it, regardless of which process created it. The operating system's credential service is not exempt. A QUIC connection from WebTransport is not exempt. A DNS lookup triggered by a prefetch hint is not exempt. There is no browser setting to route around, because the routing decision is made below every browser.

This is why the researchers noted that VPN users are unaffected. It is not that VPN software is better written. It is that it operates at a layer where these bypasses have nowhere to go. If you want the full argument for that distinction, our explanation of what a VPN is sets out the mechanics, and our VPN rankings cover which providers we have leak-tested with our own tools.

The honest counterpoint is that a VPN moves your trust rather than eliminating it. Your provider can see what your relay partner could not. Private Relay's two-hop split genuinely is a stronger trust model on paper. It is simply a stronger model applied to a narrower slice of your traffic, with a boundary that turned out to be leakier than documented.

Apple's other privacy features do not cover this

Apple ships several privacy features with similar names, and people routinely assume that having one means being covered by another. None of the others touch this problem.

Hide My Email generates forwarding aliases so a service never learns your real address. It concerns email identity and has no effect on network routing. Mail Privacy Protection loads remote images in mail through a proxy so senders cannot use tracking pixels to log when you opened a message or from where; it applies to the Mail app, not to Safari. Intelligent Tracking Prevention limits how long cross-site cookies and storage survive in Safari, which is about state rather than addresses.

The closest-sounding one is the "Limit IP Address Tracking" toggle in Wi-Fi settings, which is simply the per-network switch for Private Relay itself rather than a separate protection. Turning it on for one network does not enable anything additional.

The distinction that matters is that all of these operate on content, identity, or storage. Your IP address is disclosed by the act of connecting, before any of those layers is involved, which is why only something that changes the network path can change it. We cover the full set of options in how to hide your IP address.

What actually helps right now

Two rows in that table exist to steer people away from advice that is already circulating. Turning Private Relay off is worse than doing nothing. Turning off passkeys does not help either, because the leaking request is triggered by the page rather than by anything stored in your keychain, and disabling passkeys would weaken your account security in exchange for nothing.

Lockdown Mode as a blunt instrument

Lockdown Mode disables large parts of the web platform surface, including WebTransport, and it is the strongest control Apple ships today. It is also genuinely disruptive: web fonts break, some link previews stop working, and a number of ordinary sites degrade or fail.

It is designed for people facing targeted attacks from well-resourced adversaries, and for that population the tradeoff is clearly worth it. For someone who simply prefers that advertisers not follow them between sites, it is a heavy tool for the job, and a system VPN closes more of this particular problem with far less collateral damage.

macOS has the same engine and the same exposure

Coverage has focused on iPhones, but Safari on macOS runs WebKit and supports Private Relay through the same iCloud+ subscription. The proxy configuration API involved was introduced in iOS 17 and macOS 14 together.

macOS users do have one meaningful advantage: the platform permits browsers that ship their own engines. Chrome on macOS uses Blink and Firefox uses Gecko, so neither inherits WebKit's behavior. If you rely on Private Relay for privacy on a Mac, note that the protection is tied to Safari, and that switching browsers changes which engine you are exposed to rather than adding protection by itself.

Does this affect Android or Windows?

Not directly. All three bypasses are specific to WebKit and to Apple's handling of proxy configuration, and neither Android nor Windows has an equivalent to iCloud Private Relay.

The underlying lesson does transfer, though. Any privacy tool that operates inside a single application shares the same structural weakness on any platform: it can only govern what that application sends. Browser proxy extensions, per-app proxies, and in-app privacy modes are all subject to the same class of gap. The specific bugs are Apple's. The category is not.

The same pattern played out with WebRTC in 2015

Anyone who has followed browser privacy for a decade will recognize the shape of this. It has happened before, in almost exactly the same way, and the precedent is genuinely useful for predicting how it resolves.

In early 2015 researchers demonstrated that WebRTC, the API behind in-browser voice and video calling, would disclose local and public IP addresses to any page that asked. It did so through a legitimate feature that needed real network addresses to negotiate a peer connection, and it did so even when the user was connected to a VPN, because the addresses were gathered by a component that operated outside the browser's normal request path. Millions of VPN users discovered that a tunnel they trusted did not cover a channel they had never heard of.

The resolution took years and arrived in layers. Browsers added policy controls, VPN providers began blocking the API in their client software, extensions appeared to disable it, and eventually the default behavior changed. In the meantime, the practical answer for users was a test: load a page that triggers the API and see which address comes back. That is exactly what our WebRTC leak test still does, and why our IPv6 leak test exists for the parallel case where a tunnel covers IPv4 and quietly ignores IPv6.

The lesson from that cycle applies directly here. New platform capabilities keep arriving that need to make network connections, each is designed by a team focused on its own use case, and the privacy boundary has to be re-established for every one of them. Expect this to be fixed, expect the fix to take longer than it should, and expect another feature to raise the same question in a few years.

Why passkeys are still worth using

Because WebAuthn is named in this research, some readers will conclude that passkeys are a privacy liability. They are not, and it is worth separating the two cleanly.

Passkeys are phishing-resistant by design and remove the shared secret that makes password reuse dangerous. They are one of the strongest practical security upgrades available to ordinary users. The bypass here does not involve your credentials, does not expose any key material, and does not require you to have a passkey at all. It abuses a validation fetch that the operating system performs on behalf of a page.

The fix belongs in how that fetch is routed, not in whether you use passkeys. Abandoning them over this would trade a serious security gain for no privacy improvement.

What Apple needs to change

The specific fixes are narrow. Prefetch resolution should go through the configured proxy or not happen at all when one is set. The credential service should honor the proxy configuration of the session that triggered the request, or the platform should refuse to fire related origin fetches without interaction. WebTransport should apply the proxy settings of the network session that created it.

The structural fix is harder and more important. Every one of these is the same mistake repeated in three places: a component made a network request without inheriting the privacy configuration of the context that caused it. Patching three call sites leaves the fourth, whenever it ships. What would genuinely resolve this is treating proxy configuration as a property that propagates by default to anything acting on a page's behalf, so that a new feature is private unless it explicitly opts out.

If you run a website

There is an operator side to this that deserves stating plainly, because the same research that describes a privacy failure also describes a capability.

These bypasses are trivially implementable. A prefetch hint is one line of markup. A related origin request needs a hostname you control and a well-known path. A WebTransport connection is one constructor call. None require a vulnerability scanner, a payload, or anything a security product would flag. Any site could add them today and begin collecting real addresses from visitors who believe they are proxied.

Do not do this. Deliberately defeating a user's stated privacy configuration is the kind of processing that regulators treat as covered by consent requirements, and in the EEA and UK an IP address is personal data regardless of how you obtained it. Collecting one through a channel specifically designed to evade the user's protection is a poor position to defend, and it is the same category of behavior that drew scrutiny to fingerprinting in the first place. We wrote about where that line now sits in Google's move to use IP addresses for ad personalization.

The legitimate operator response is the opposite one. If your fraud or geo logic currently penalizes relay egress addresses, this research is a good reason to revisit it, because a growing share of ordinary customers arrive that way and blocking them costs you real transactions.

Disclosure timeline

The sequence is short and still open. Bakry and Mysk published their findings on August 4, 2026, having filed a series of WebKit bug reports covering the individual behaviors. 404 Media independently reproduced the leak against the researchers' proof of concept and reported the confirmation the same week. Apple told 404 Media it is investigating and did not commit to a timeline.

Psylo shipped a fix in version 1.3.1 before the disclosure, blocking prefetch hints and disabling WebTransport and WebAuthn by default while offering per-context opt-in toggles. That a third-party developer mitigated this in their own product ahead of the platform vendor is a reasonable indication of how tractable the browser-side fixes are.

What to watch next

Three things will tell you how this resolves. The first is whether Apple ships fixes in a point release or holds them for a major version, which indicates how seriously the company treats the severity. The second is whether the fixes address the three named features individually or change how proxy configuration propagates, which determines whether a fourth instance appears later. The third is whether Apple says anything about the two-year WebAuthn window, which is the part that most deserves an explanation.

Until then, the practical situation is stable and easy to state. Private Relay still protects the traffic it always protected. Three specific channels reach around it. A system-level tunnel closes all three. Nothing you toggle inside Safari does.

The bottom line

This is a real failure of a paid privacy feature, and it is also not a reason for alarm. Your device is not compromised, your accounts are not at risk, and the exposed information is a network address rather than an identity. What broke is a specific guarantee: that sites you visit in Safari cannot see where you actually connect from.

The durable lesson is architectural. Protection that lives inside an application can only govern that application, and every year the web platform adds new ways for something other than the application to make a request. Private Relay was a genuinely thoughtful design that made a reasonable assumption about its own boundary, and the boundary moved underneath it. If you need a guarantee that survives that kind of drift, you need it enforced below the browser, which in practice means a system VPN.

Start by establishing your own baseline. Check what address you are presenting, confirm it with the proxy check, and run the DNS leak test to see which resolvers you are really using. If you are on an iPhone and want the full picture of which address applies to which connection, our guide to finding your IP on iPhone walks through every path your traffic can take, including how Private Relay changes what you see.