iCloud Private Relay Is Leaking Your Real IP Address

You turned on iCloud Private Relay for one reason: so the sites you visit would stop seeing where you connect from. That is the entire pitch. Apple relays your Safari traffic through two hops so no single party — not your internet provider, not the website — can tie your identity to your destination. For a specific class of request, that promise does not hold.

On August 4, 2026, security researchers Tommy Mysk and Talal Haj Bakry published findings showing that a website can obtain your real IP address while Private Relay is switched on and working normally. Press coverage followed on August 5, picked up by MacRumors, 9to5Mac, TechCrunch, and The Hacker News among others. There are three separate leak paths, they are unrelated to each other in mechanism, and the sharpest of the three involves passkeys — the login technology Apple has spent years promoting as the safer replacement for passwords.

This article walks through what Private Relay actually promises, what the researchers demonstrated, how each of the three leaks works, how to test your own Mac, and what is genuinely worth doing about it. A note on scope before anything else: this is a leak of your network identity, not of your browsing content and not of your accounts. Nobody is reading your encrypted traffic. Nobody is getting into your iCloud. What leaks is an IP address, and whether that matters to you depends entirely on who you are and who is looking.

Key Takeaways

• Three separate vectors, one outcome. Mysk and Haj Bakry demonstrated that WebAuthn/passkey ceremonies, DNS prefetching, and WebTransport can each surface your real IP address to a website while Private Relay is enabled. They are independent bugs that happen to converge on the same failure.
• The passkey leak does not require you to have a passkey. The researchers found that a site only needs to start the ceremony — sites that use passkeys or merely pretend to use them can trigger the request. You never have to click anything or complete a login.
• This is an IP leak, not a breach. Nothing about the encrypted contents of your browsing is exposed, no account is compromised, and no CVE has been assigned. What is exposed is network identity: your real address and, in the DNS case, your real resolver.
• Apple is investigating and no fix exists today. Apple told 404 Media it is looking into the report. 9to5Mac reported that Apple's status message to the researchers indicated it is planning to address the issue, with a fix targeted for fall 2026. MacRumors characterised the problem as baked into how WebKit works.
• Turning Private Relay off is the wrong response. It still does real work against passive observers on your network. The reasonable upgrade for a genuine threat model is a real VPN, with the honest trade-off that you are moving your trust from Apple to a VPN vendor.

What iCloud Private Relay Actually Is, and What Apple Promises It Does

Before judging the leak, it helps to be exact about the claim being leaked from — because a lot of the confusion around this story comes from people expecting Private Relay to be something it was never sold as.

iCloud Private Relay is an iCloud+ feature, which means it ships with a paid iCloud storage plan rather than with the operating system. Apple's positioning is consistent and fairly narrow: it is designed to keep your IP address and browsing activity hidden from network providers and from the websites you visit. That is the promise. It is not "we will encrypt everything on your Mac" and it is not "we will make you anonymous."

The two-hop design

The architecture is the interesting part, and it is genuinely well thought out. When Private Relay is active, a request from Safari does not travel directly to the destination server. It goes through two proxies in sequence.

The first hop, the ingress proxy, is operated by Apple. Apple knows who you are — you are signed into an iCloud account, after all, and your device connected from a particular network. What Apple does not get is the destination. The address of the site you are visiting is encrypted such that the ingress proxy cannot read it.

The second hop, the egress proxy, is operated by a third-party content delivery partner rather than by Apple. This proxy is the one that actually talks to the destination website. It knows where you are going. It does not know who you are, because it never saw your original IP address or your iCloud identity — it received the request from Apple's ingress proxy.

The result is a deliberate split of knowledge. Neither party holds both halves of the sensitive pair. Apple knows who but not where. The partner knows where but not who. The website at the end of the chain sees the egress proxy's address, not yours, and Apple additionally offers a coarse location setting so that the address the site sees still roughly matches your region — useful for local search results and news, without pinpointing you.

It is a better design than most people give it credit for, and it costs you effectively nothing extra if you already pay for iCloud storage. If you want a broader tour of how this sits alongside the rest of the platform's protections, our macOS Tahoe security and privacy guide covers the surrounding features.

The crucial framing: it is not a VPN

Here is the part that matters for understanding the leak. Private Relay is not a VPN and Apple has never described it as one.

A VPN, when it is configured properly, captures traffic at the network layer. Every application on the machine, every protocol, every socket — it all goes through the tunnel because the operating system's routing table sends it there. That is why VPNs are heavy, why they break things, and why they sometimes need a kernel extension or a system network extension to work.

Private Relay operates at a much narrower scope. It covers:

• Safari browsing traffic. This is the headline use case.
• DNS resolution. Your DNS queries are meant to go through the relay so your resolver does not become a log of everywhere you have been.
• A slice of unencrypted app traffic. Insecure HTTP requests made by apps get pulled into the relay as a hardening measure.

That is the perimeter. Traffic from Chrome does not go through it. Traffic from your mail client does not go through it. Encrypted app traffic from third-party apps does not go through it. If an application opens its own connection using its own networking stack, Private Relay is not in that path and was never claiming to be.

This distinction is not a technicality — it is the entire frame for evaluating the new findings. Two of the three leaks the researchers found are, at some level, cases of a request escaping the perimeter that Private Relay draws. The bug is not that the perimeter exists. The bug is that requests originating from what the user experiences as "Safari browsing" end up outside it, invisibly, with no signal to the user that anything left the tunnel.

What the Researchers Found

Tommy Mysk and Talal Haj Bakry are not new to this. They have a long track record of picking apart privacy claims on Apple platforms — often finding that the gap between the marketing description and the implementation is wider than anyone expected. Their pattern is consistent: build a demonstration, publish it, and let the artifact make the argument rather than the press release.

Their findings on Private Relay are dated August 4, 2026. Coverage appeared the following day, August 5, across MacRumors, 9to5Mac, TechCrunch, and The Hacker News, among other outlets.

The core claim in plain English: a website can obtain your real IP address even when iCloud Private Relay is enabled. Not through some exotic side channel that requires you to be attacked first, and not by exploiting a misconfiguration on your end. Through ordinary web platform features that any site can invoke.

The three vectors are:

1. WebAuthn / passkeys. The network request that a passkey login makes is issued by the operating system's credential service, not by Safari, so it never enters the proxied path.
2. DNS prefetching. A performance feature added in the OS 26 generation that reveals the user's real DNS resolver.
3. WebTransport. A newer transport API added in the 26.4 generation that can open a direct HTTP/3 connection which goes around the proxy.

The exposure is to Safari and WebKit-based browsing. On iOS, where most jurisdictions still require every browser to use WebKit under the hood, this means alternative browsers are affected too — switching from Safari to another iPhone browser does not change the engine doing the work. On the Mac the situation is different: the exposure centres on Safari and on apps that embed WebKit for their in-app browsing, while non-WebKit browsers like Chrome and Firefox use their own engines and their own network stacks. That is a meaningful difference for Mac users, and we will come back to what it does and does not buy you.

Apple's response, as reported: the company told 404 Media it is investigating the report. 9to5Mac reported that Apple's status message to the researchers indicated it is planning to address the issue they reported, with a fix targeted for fall 2026. That is the extent of what has been publicly attributed to Apple. No specific release has been named, no ship date has been confirmed by Apple in public, and no CVE has been assigned to any of the three vectors.

No fix exists today. MacRumors characterised the problem as baked into how WebKit works — which is a fair way to describe a class of bug where the fix is not a patch to one function but a rethink of which subsystem owns a network request.

The Passkey Vector, Explained Properly

Of the three, this is the one worth understanding in detail. It is the most surprising, the hardest to avoid, and the one with the most uncomfortable implication.

What a WebAuthn ceremony actually is

Passkeys are built on WebAuthn, a web standard for public-key authentication. The mental model most people carry is roughly right: instead of sending a password to a server, your device holds a private key, the server holds the matching public key, and logging in means proving you control the private key by signing a challenge. Nothing reusable crosses the wire. Phishing a passkey does not work the way phishing a password does, because the signature is bound to the origin.

The sequence of steps that accomplishes this is called a ceremony. The site's JavaScript calls into the browser, the browser asks the platform to produce or verify a credential, you authenticate locally with Touch ID or your device passcode, and a signed assertion comes back. On Apple platforms the credential itself lives in the Passwords app and syncs through iCloud Keychain. If you want the wider context on how Apple has been building out that side of things, we looked at it in our piece on the Passwords app and automatic password change.

The part almost nobody thinks about is that a ceremony is not purely local. Part of it involves fetching data over the network — the relying party's configuration, the association data that ties a site's domain to the credentials allowed to serve it. Something has to make an HTTPS request to get that.

Who makes the request

This is where it goes wrong. Quoting the reporting on the researchers' explanation:

WebKit hands WebAuthn ceremonies to the operating system's credential service, which issues the HTTPS request itself, directly from the device and unaware of any proxy the host app configured.

Read that carefully, because every clause is doing work. WebKit does not perform the ceremony itself; it delegates to a system service that owns credentials. That service then makes its own outbound HTTPS request. And critically, it is unaware of any proxy the host app configured — the credential service does not know or care that Safari has been set up to route its traffic through Private Relay's two-hop path. It is a different process with a different networking configuration, doing what it was designed to do.

The consequence, again as reported:

Because the fetch is issued by the operating system's credential service rather by Safari, it never enters Private Relay's proxied path.

So the request goes out directly from your device, from your real IP address, to a server the website controls. The website sees the connection. It logs the address. Private Relay was running the entire time and was simply not in that path.

From an architectural standpoint you can see how this happened without anyone being careless. Credential handling should be isolated from the browser — that separation is a security property, not a mistake. Keeping key material out of a process that runs untrusted JavaScript from arbitrary websites is exactly right. The problem is that the isolation was drawn for security and nobody re-drew the privacy boundary to match. The credential service inherited process isolation and did not inherit the proxy configuration.

The sharpest point: you do not need a passkey

Here is the detail that turns this from an interesting architecture note into an actual privacy problem.

The researchers note that this fires on sites that use or merely pretend to use passkeys. A site can trigger the ceremony without you completing any login. You do not need to have a passkey for that site. You do not need to have an account at all. You do not need to click a login button, approve a Touch ID prompt, or interact with anything.

A page can invoke the API and the network request happens. Whether the ceremony ultimately succeeds, fails, or is abandoned is irrelevant to the leak, because the leak occurs at the fetch, before any of the authentication logic matters.

That inverts the meaning of the feature. WebAuthn exists to make authentication safer. In this configuration, the mere invocation of the authentication machinery becomes a de-anonymisation trigger that any page can pull, silently, on load. A tracker does not need to compromise anything. It needs to include a snippet that starts a ceremony nobody will ever finish, and it collects the real IP of every Private Relay user who loads the page.

There is no user-visible signal when this happens. No prompt, no permission sheet, no indicator in the toolbar. The design assumption was that starting a credential ceremony is a benign act, and under normal circumstances it is.

The DNS Prefetching Vector

The second leak is smaller in impact but instructive, because it shows the same underlying pattern in a completely different subsystem.

What prefetching is for

Loading a web page is a chain of dependent lookups. The browser gets the HTML, discovers it references a stylesheet on one domain, a font on a second, an analytics script on a third, and images on a fourth. Each of those domains needs a DNS resolution before a connection can even begin, and DNS resolution takes time — tens of milliseconds when things go well, considerably worse on a bad mobile connection.

DNS prefetching is a straightforward optimisation for this. While the browser is still parsing the page, it looks ahead at the links and resources referenced, and resolves those hostnames in advance. By the time the parser reaches the point of actually needing a connection, the address is already cached and the connection starts immediately. It is the kind of change that shows up as a real improvement in page load metrics, which is exactly why browser engineers keep adding features like it.

This particular implementation arrived in the OS 26 generation — the Tahoe-era releases across Apple's platforms.

What it exposes

The researchers found that these prefetch queries reveal the user's real DNS resolver.

Under normal Private Relay operation, DNS is supposed to be part of what the relay covers. That is deliberate and important: if your queries went to your ISP's resolver in the clear, your ISP would hold a timestamped list of every domain you looked up, which is a near-complete browsing history regardless of how well the actual traffic is encrypted. Private Relay exists in large part to break exactly that link.

When prefetch queries escape that path, they go to whatever resolver your device is actually configured to use — typically the one handed to you by DHCP on your current network, which usually means your ISP, your employer, or the operator of whatever Wi-Fi you are on.

What leaks here is narrower than a raw IP address. An observer learns which resolver you use, which is a strong signal about which network you are on and often which provider serves you. Combined with other signals it contributes to a fingerprint. It also means the resolver operator sees lookups that were supposed to be shielded from them.

It is a smaller problem than the passkey vector and it produces a coarser signal. It is not nothing. If you have ever wrestled with DNS behaviour on macOS while running a tunnel, some of this will feel familiar — the interaction between system resolvers and proxied traffic is a persistent source of confusion, and our macOS VPN troubleshooting guide covers the general shape of those problems.

The WebTransport Vector

The third leak involves the newest technology of the three, and it is the cleanest illustration of the structural issue.

What WebTransport is for

WebTransport is a modern web API for low-latency, bidirectional communication between a browser and a server. Think of it as the successor to WebSockets, built on top of HTTP/3 and QUIC rather than on TCP.

The reason it exists is that a meaningful class of web applications needs something better than request/response. Multiplayer games need to push state constantly and tolerate the occasional dropped update better than they tolerate delay. Live video and audio applications need the same. Collaborative editors, remote desktop tools, real-time telemetry dashboards — all of them want a persistent channel with low overhead and the ability to send unreliable datagrams when reliability is not worth the latency cost.

WebTransport delivers that by running over QUIC, which is a UDP-based transport with encryption built in and no head-of-line blocking across streams. It is genuinely good engineering for the problem it solves.

Apple's implementation arrived in the 26.4 generation.

Why a direct HTTP/3 connection defeats the proxy

Private Relay's proxying is built around conventional web traffic — the request patterns that Safari's normal networking path produces. Those go through the two-hop ingress/egress chain.

The researchers found that WebTransport can open a direct HTTP/3 connection that goes around the proxy. Once that connection is established directly from the device to the destination server, the server sees the device's real address, the same as with any unproxied connection.

The pattern here is identical to the passkey case even though the code involved is entirely unrelated. A new capability was added to the platform. The capability opens network connections. The proxying layer was built with a model of what "network connection" means that predates the new capability. Nothing connects the two, and the new capability quietly operates outside the perimeter.

That is why MacRumors' framing — that the problem is baked into how WebKit works — is more than rhetorical. The engine's evolution keeps adding subsystems that can talk to the network. Unless the proxy boundary is enforced at a level that all of them must pass through, each new subsystem is a candidate for the same bug. Fixing three specific leaks does not, by itself, prevent a fourth.

How to Test Your Own Mac

The researchers built a public test tool, which is the most useful thing about this disclosure from a reader's point of view. You do not have to take anyone's word for it.

The tool is at https://leaks.psylo.app/.

Running the test

1. Confirm Private Relay is on first. There is no point testing the leak if the relay is not running. Open System Settings, click your Apple Account at the top of the sidebar, select iCloud, then Private Relay, and confirm it is enabled. Skip ahead to the section on checking Private Relay status if you are unsure — it turns itself off more often than most people realise.
2. Note what your relayed IP should look like. Any "what is my IP" service, loaded in Safari with the relay on, will show you an address belonging to Apple's egress partner rather than your own. That is your baseline: the address a site is supposed to see.
3. Visit the test page in Safari. Use Safari specifically, since the vectors are WebKit-specific on macOS. The tool runs its checks and reports what it was able to observe about your connection.
4. Compare the results. A clean result means the addresses the tool observed through each tested vector match your relayed address — the proxy held. A leaking result means at least one vector surfaced an address that is not the relay's, and that address is yours.
5. Test on each network you care about. Results can differ between your home network, a corporate network, and public Wi-Fi, partly because Private Relay's own availability differs between them.

The honest caveat

A test tool tells you about the vectors it implements. It does not tell you about every possible vector.

This matters more than the usual disclaimer, because of the structural point above. If the underlying issue is that new WebKit subsystems can open network connections outside the proxy boundary, then the set of vectors is not fixed — it is whatever has been discovered so far. A clean result on a tool that checks three things means those three things did not leak in that test, on that network, in that moment. It is meaningfully better than not knowing. It is not a certificate of anonymity.

Treat the test the way you would treat any negative security result: as the absence of evidence for a specific set of problems, not as evidence of absence generally.

What You Can Actually Do Right Now

There is no fix to install. What follows is ranked roughly by how much it actually helps, and each entry includes what it costs you, because a mitigation with an unstated trade-off is a sales pitch rather than advice.

1. Use a real VPN if your threat model justifies one

This is the mitigation reported in coverage, and it is the only option on this list that addresses the problem at the right layer. A properly configured VPN captures traffic at the network layer, below the point where any of these three vectors operate. The credential service's HTTPS request, the prefetch DNS query, and the WebTransport QUIC connection all go through the operating system's networking stack, and a system-level VPN sits underneath all of it.

The trade-off is real and you should say it out loud before acting on it: you are moving your trust from Apple to a VPN vendor. Private Relay's two-hop design is specifically constructed so that no single party sees both your identity and your destinations. A conventional single-hop VPN does not have that property. Your VPN provider sees both. You are betting on their logging policy, their jurisdiction, their operational security, and their honesty, and unlike Apple's architecture, that bet is not enforced by the design — it is enforced by a promise in a privacy policy.

That is not an argument against VPNs. It is an argument for picking one deliberately: independently audited, clear about jurisdiction, with a business model that does not depend on your data. If you go this route, expect to spend a while on configuration quirks; our macOS VPN troubleshooting guide covers the failure modes that catch people out on macOS specifically.

2. Do not turn Private Relay off

This is the most common instinct and it is backwards.

Private Relay still does real work against passive observers. Your ISP still cannot build a browsing log from your DNS queries for everything that does go through the relay. The operator of the coffee shop Wi-Fi still cannot watch which sites you visit. The vast majority of your Safari traffic is still proxied and still hides your address from the sites you visit. The leaks are specific paths that escape, and they require the site to actively try — a page has to invoke a passkey ceremony, or use WebTransport, or trigger prefetch behaviour.

Switching the relay off does not close a single one of these leaks. It just adds back all the exposure the relay was successfully preventing. You end up with strictly less privacy than you had, in exchange for nothing.

3. Be deliberate about which sites you let start a ceremony

This is weaker advice than it sounds, and it is worth being honest about why.

The passkey vector fires without interaction. You cannot decline a ceremony you were never asked about. So there is no setting to toggle and no prompt to refuse.

What you retain is control over which pages you load at all. If you are doing something where IP exposure genuinely matters, be conscious that any page you open — including one you land on from a link, including an embedded in-app browser view — is a page that can invoke the vector. That argues for compartmentalisation: do the sensitive browsing in a deliberately chosen environment rather than in the same session as everything else. It does not argue for a checklist of sites to avoid, because the sites that would exploit this are not the ones that announce themselves.

4. Understand what Lockdown Mode does and does not do here

Lockdown Mode is Apple's extreme protection setting for users at risk of targeted attack. It disables a long list of web technologies, including just-in-time JavaScript compilation and various complex features, on the theory that attack surface you do not have cannot be exploited.

It is worth considering if you are in the population Lockdown Mode was built for, since its whole approach is to remove functionality rather than to patch specific bugs, and features removed cannot leak. But be careful about the reasoning: Lockdown Mode is a hardening posture, not a targeted fix for these three vectors, and none of the reporting frames it as a remedy for this issue. Treat it as a reasonable thing to evaluate if you are already a candidate for it, not as the answer to this specific problem. It also breaks a great deal of ordinary web browsing, which is by design and is why Apple does not suggest it for general use.

5. Know what switching browsers does — and where it does nothing

Platform matters here.

On iOS, switching browsers does not help. Most jurisdictions still require every browser to use WebKit as its engine, so the alternative browser you install is a different interface over the same engine with the same vectors. Chrome on iPhone is not Chrome's engine.

On the Mac, the situation genuinely differs. Non-WebKit browsers use their own engines and their own network stacks, so they behave differently with respect to these specific WebKit-originated vectors. But note carefully what that does and does not buy you: Private Relay does not proxy non-Safari browser traffic in the first place. Moving to Chrome or Firefox on macOS does not put you behind the relay — it takes you outside it entirely. You have not fixed a leak; you have opted out of the protection. That is only an improvement if you are pairing it with a VPN that covers everything. If you spend most of your time in Safari and want to get more out of it, our Safari power user guide is a better use of your attention than a browser migration undertaken for the wrong reason.

Do not overpromise any of this to yourself. Options 2 through 5 reduce exposure or avoid making things worse. Only option 1 addresses the vectors at the layer where they operate, and it does so by substituting one trust relationship for another.

Who Should Actually Care

Privacy stories reward hysteria and punish proportion, so let us be exact about who this affects and how much.

For most people, this is erosion, not emergency

If you are an ordinary user with an ordinary threat model, here is the honest assessment: a feature you pay for is doing less than advertised in specific circumstances, which is annoying and worth Apple fixing, and the practical consequence for you is close to zero.

Consider what actually leaks. Your IP address, to a site that deliberately went looking for it. Most sites already have far better identifiers for you — you are signed in, you have cookies, you have a browser fingerprint that is considerably more distinguishing than an IP address that changes when you move between networks. For the advertising ecosystem, an IP address is a supplementary signal, not the crown jewel. The companies exploiting this, if any are, are the ones already tracking you comprehensively through means Private Relay was never going to stop.

What you lose is a layer of defence in depth that you had reason to believe was there. That is a legitimate complaint. It is not a reason to change how you live.

Who should act

The people who should treat this seriously are those whose threat model actually includes IP-based deanonymisation. Concretely:

• Journalists working with sources, where the connection between a reporter and a location or a network is itself sensitive information.
• Activists and organisers in environments where a network address maps to a real-world identity that carries risk.
• People avoiding a specific individual — a stalker, an abusive ex-partner, someone with the technical means and the motivation to run a site or a link and read what connects to it. This is the case where an IP address is genuinely dangerous, because it can approximate a location and confirm that a specific person visited a specific link.
• People whose employer or institution should not know what they are researching, particularly on a network the institution controls.

If you are in one of these groups, the correct posture was never Private Relay alone. It was a properly chosen VPN or Tor, appropriate compartmentalisation, and an assumption that any convenience feature can fail. This disclosure is a reminder of that principle rather than a change to it. Our Mac security and privacy guide goes deeper on building a layered setup, and if you are thinking about reducing your exposure more broadly, running AI tools locally rather than in the cloud follows the same reasoning applied to a different part of the stack.

The middle ground

Between "irrelevant to you" and "your safety depends on it" sits everyone else, and the reasonable posture there is calibration rather than action. Understand that Private Relay's coverage is narrower than the mental model most people carry. Stop treating it as a VPN, because it is not one and now you have a concrete demonstration of the difference. Keep it on, since it still helps against the observers it was designed for. And if you find yourself doing something where being identified would actually matter, reach for a tool built for that job rather than relying on the one that happens to be already enabled.

How to Check Whether Private Relay Is Even On

There is a strong chance Private Relay is off right now on at least one network you use, and that you have no idea. It disables itself in several situations without much ceremony, so before worrying about leaks it is worth confirming the relay is running at all.

The main setting

On a Mac:

1. Open System Settings.
2. Click your Apple Account at the top of the sidebar.
3. Select iCloud.
4. Find Private Relay in the list and open it.
5. Confirm the toggle is on. While you are there, check the IP Address Location setting — "Maintain General Location" keeps regional content working, while "Use Country and Time Zone" broadens your apparent location further.

If you do not see Private Relay at all, the usual explanation is that you are not on a paid iCloud+ plan. It is an iCloud+ feature and does not appear on the free storage tier.

The per-network toggle almost nobody knows about

This one catches people constantly. Private Relay has a separate on/off state for each individual Wi-Fi network, independent of the global setting.

To check it: open System Settings, go to Wi-Fi, click Details next to your connected network, and look for the Private Relay option there. It can be off for that specific network while the global setting is on.

This is genuinely useful behaviour — it is how you keep the relay on generally while turning it off for the one corporate network that breaks without it — but it means "I turned Private Relay on" and "Private Relay is running right now" are two different statements. Check the per-network setting on any network where a test shows unexpected results.

The ways it silently turns itself off

Beyond the two toggles, several conditions disable the relay without a prominent warning:

• Unsupported networks. Some networks block the protocols or endpoints Private Relay depends on. When that happens, macOS typically offers a choice between using the network without the relay or not connecting, and whichever you picked at the time persists.
• Corporate and managed networks. Enterprises frequently disable Private Relay deliberately, because a proxy that hides destination addresses is fundamentally incompatible with network-level content filtering and monitoring. Managed devices may have it disabled by configuration profile with no user-facing toggle at all.
• Country and region restrictions. Private Relay is not available everywhere. Apple has confirmed it is unavailable in a number of jurisdictions, and in those regions the feature simply does not run regardless of your settings.
• Cellular carrier configurations. Some carriers have shipped configurations that disable it on their networks.
• Conflicting VPN or DNS configuration. Running a system VPN generally means Private Relay stands down, since the VPN takes the traffic first. Custom DNS settings and certain DNS-filtering profiles can also disable it.

The common thread is that Private Relay fails open rather than failing loudly. It stops working and you keep browsing. That is a defensible design choice for a convenience feature — the alternative is breaking people's internet — but it means periodic verification is the only way to know your actual state.

What a Fix Would Have to Look Like

It is worth thinking about what Apple actually has to build here, because it explains why the reported timeline is measured in months rather than in a point release.

The shallow fix is to patch each vector individually. Make the credential service aware of the host application's proxy configuration and route its ceremony fetches accordingly. Bring prefetch DNS queries back inside the relay's DNS path. Route WebTransport's QUIC connections through the proxy chain or refuse to establish them directly when the relay is active. Three targeted changes, three closed holes.

That would fix the reported problems and would not fix the underlying condition. The pattern across all three is the same: a subsystem that can reach the network was built without inheriting the proxy boundary. That will keep happening as long as the boundary is something each subsystem has to opt into rather than something enforced beneath all of them.

The deeper fix is architectural — enforcing the relay at a layer that every WebKit-adjacent network path must traverse, so that a new capability cannot bypass it by not knowing about it. That is a large change with real risk of breaking things, and it is the kind of work that lands in a major release rather than a security update. It would also need a clear policy for what happens to requests that genuinely cannot be relayed: fail closed and break the feature, or fail open and leak. Neither answer is comfortable, and picking one is a product decision as much as an engineering one.

A third component, and arguably the most valuable, is user-visible: some signal when a request escapes the relay. Right now the feature is entirely silent about its own coverage. You cannot tell whether the page you are on has been fully proxied, partially proxied, or not at all. That opacity is what turned three implementation gaps into a story about a broken promise, because users had no way to observe the difference between working and not working.

What to watch for in the fall 2026 releases

Based on 9to5Mac's reporting of Apple's status message to the researchers, a fix is targeted for fall 2026. That is what has been reported — Apple has not publicly committed to a specific release or date, and you should not treat it as a guarantee.

If and when something ships, the things worth checking:

• Whether all three vectors are addressed or only the passkey one. The passkey vector got the headlines. The other two are quieter and could plausibly be deferred.
• Whether the fix is targeted or structural. Release notes rarely say this directly, but the researchers will likely retest and report, and their test tool gives everyone else a way to verify independently.
• Whether anything user-visible appears. Any indication of relay coverage on a per-page basis would be a meaningful improvement over the current silence.
• Whether Private Relay's scope is redescribed. If Apple tightens the language around what the feature covers, that is informative too — it would suggest the resolution is partly about expectations rather than entirely about code.

Until then, the situation is unchanged: the leaks are real, the relay still does useful work against passive observers, and the gap between the two is where you need to make your own decision.

Troubleshooting Common Issues

Private Relay Is Greyed Out or Missing Entirely

Problem: You go to System Settings, your Apple Account, iCloud, and either Private Relay is not listed or the toggle will not respond.

Solution: Work through the causes in order. First, confirm you are on a paid iCloud+ plan — Private Relay does not exist on the free tier, and this is the most common explanation for it being absent. Second, check your region: the feature is unavailable in a number of countries and does not appear where it is not offered. Third, if the Mac is managed by an employer or school, look in System Settings under General, then Device Management, for a configuration profile — organisations routinely disable Private Relay because it defeats network filtering, and a profile-level restriction cannot be overridden locally. Fourth, verify you are signed into iCloud with the account that carries the iCloud+ subscription, not a secondary account. If all four check out and the toggle is still unresponsive, sign out of iCloud and back in, then restart.

Private Relay Keeps Turning Itself Off on One Specific Network

Problem: The relay works at home but is consistently off at the office, in a particular café, or on a specific hotel Wi-Fi.

Solution: Check the per-network toggle first, since this is almost always the cause. Open System Settings, go to Wi-Fi, click Details next to that network, and look for the Private Relay setting there. It is independent of the global switch, and if you ever dismissed the "this network blocks Private Relay" prompt by choosing to continue without it, the choice was remembered for that network. Turn it back on and see whether the connection still works. If the network genuinely blocks the relay, you will be prompted again, and at that point you know the block is upstream rather than a stale setting. Corporate networks in particular tend to block it deliberately at the firewall, and there is no client-side workaround — if you need address privacy on a network like that, a VPN is the only route, assuming the network permits one.

The Test Tool Shows a Leak and You Want to Know What to Do

Problem: You visited the researchers' tool, it reported that your real address was visible through one or more vectors, and you want a next step.

Solution: First, do not interpret this as a compromise. A leak result means a site could learn your IP address; it does not mean anything was stolen, accessed, or breached, and there is no account to secure or password to change. Second, confirm the result is about the vectors rather than about the relay being off — check the global and per-network Private Relay settings and retest, because a disabled relay will show your real address through every path and is a completely different problem with an easy fix. Third, if the relay is confirmed on and the leak persists, you have reproduced the reported behaviour and there is no user-side fix available. Decide based on your threat model: for most people the correct response is to note it and continue, and for those who genuinely need address privacy, a VPN is the available mitigation with the trust trade-off described earlier. Retest after any fall 2026 update.

Sites Block You or Break Because You Are Using Private Relay

Problem: A banking site refuses to load, a streaming service claims you are in the wrong country, a store's checkout fails, or a site repeatedly challenges you with CAPTCHAs.

Solution: This happens because the site sees the egress proxy's address rather than yours, and either it does not recognise the address as residential, or the address geolocates somewhere unexpected, or it belongs to a shared range that has been flagged. Start with the location setting: in the Private Relay panel, switch IP Address Location to "Maintain General Location" if it is set to the broader country-level option, which resolves most geographic mismatches. If that is not enough, use the per-network toggle to disable the relay just on that network rather than globally, or use a different browser for the specific site — remembering that non-Safari browsers on macOS are outside the relay anyway. Turning the relay off globally to fix one stubborn site is an overcorrection you will forget to reverse.

A VPN and Private Relay Conflict With Each Other

Problem: You connect a VPN and Private Relay reports itself as inactive, or the two together produce broken DNS, failed connections, or unusably slow browsing.

Solution: Understand first that this is largely expected. A system VPN captures traffic at the network layer before Private Relay would see it, so macOS generally stands the relay down when a VPN is active — that is not a bug and it does not leave you unprotected, since the VPN is now covering strictly more traffic than the relay did. The practical guidance is to pick one and let it own the path. If you are running a VPN for the reasons discussed in this article, the relay standing down is the correct outcome. If you are seeing actual breakage rather than just the relay reporting inactive, the usual culprits are conflicting DNS configuration, a VPN client that only partially captures traffic, or a leftover network extension from a previously installed VPN. Remove old VPN configuration profiles under System Settings before debugging further, since stale profiles cause a disproportionate share of these problems.

FAQ

Does this mean my browsing history was exposed?

No. What leaks is your IP address — network identity, not content. The encrypted contents of your browsing remain encrypted, and nothing about which pages you read is revealed by these vectors beyond the fact that you connected to a site that was already trying to identify you. No account credentials are involved and no account was compromised.

Should I stop using passkeys because of this?

No. Passkeys remain substantially more secure than passwords — they are phishing-resistant and nothing reusable crosses the network. The leak is not a weakness in passkey authentication itself; it is that the network request supporting the ceremony bypasses Private Relay. Abandoning passkeys would trade a real security gain for a marginal privacy one.

Has a CVE been assigned to this?

No CVE has been reported for any of the three vectors. The findings were published by Mysk and Haj Bakry on August 4, 2026 and covered in the press the following day. Apple told 404 Media it is investigating. Be wary of any source citing a specific CVE identifier for this issue, since none has been published.

Does using Chrome or Firefox on my Mac fix it?

Not in the way people assume. Those browsers use their own engines and are not affected by these WebKit-specific vectors, but Private Relay never proxied their traffic in the first place. Switching does not put you behind the relay — it removes you from it entirely. That only helps if you pair it with a VPN covering everything.

Is this different on my iPhone than on my Mac?

Yes. On iOS, most jurisdictions require all browsers to use WebKit, so every browser on the device shares the same exposure and switching apps changes nothing. On the Mac, only Safari and apps embedding WebKit are affected, since other browsers ship their own engines. The vectors themselves behave the same way on both platforms.

When will Apple fix this?

9to5Mac reported that Apple's status message to the researchers indicated the company is planning to address the issue, with a fix targeted for fall 2026. Apple has not publicly committed to a specific release or date beyond confirming to 404 Media that it is investigating. No fix is available today, and MacRumors described the problem as baked into how WebKit works.

Conclusion

The findings from Mysk and Haj Bakry are real, they are well documented, and they are worth Apple fixing properly rather than patching narrowly. Three separate WebKit subsystems — the credential service handling passkey ceremonies, DNS prefetching, and WebTransport — can each put your real IP address in front of a website that goes looking for it, while Private Relay sits there reporting itself as enabled. The passkey vector is the sharpest of the three because a site only has to start the ceremony, not complete it, and needs nothing from you at all.

What this is not: a breach, an account compromise, or a reason for alarm. Private Relay was never a VPN, never claimed to be one, and still does the job it was built for against the observers it was built to stop — your ISP, the network you are sitting on, the passive watchers who see traffic without being able to make a site actively probe you. That protection is intact and switching the feature off would only surrender it for nothing in return.

What it is: a clear demonstration that the feature's coverage is narrower than the mental model most people carry, and that the boundary is not enforced anywhere that new platform capabilities have to respect. If your threat model genuinely includes someone learning your IP address, the answer was always a tool built for that job, with the trust trade-off understood and accepted. If it does not, note this, keep the relay on, run the test if you are curious, and watch what ships in the fall.

Related reading: Mac Security & Privacy Guide 2026