# Apple's Privacy Relay Has a Leak Problem — And Passkeys Made It Worse
Apple spent years marketing iCloud Private Relay as the privacy feature that even Apple itself can't see through. The dual-hop architecture was a genuine engineering commitment: split the request between two relays, give each one only half the picture, and no party — not Apple, not the exit relay, not the destination site — could link your identity to your browsing. For privacy-conscious users who didn't want a full VPN, it was a meaningful guarantee.
Researchers Talal Haj Bakry and Tommy Mysk have now documented three ways that guarantee falls apart, and one of them is particularly difficult to dismiss.
## Three Holes, One Engine
All three vulnerabilities root in WebKit, the browser engine Apple mandates for every browser on iOS and iPadOS. That last part is what makes the scope so broad — this isn't a Safari-only problem. Chrome, Firefox, Edge, Brave on your iPhone all run WebKit underneath, which means they all inherit these behaviors.
The three mechanisms:
DNS prefetching resolves hostnames the browser anticipates you'll need before you actually click anything. WebKit does this using the device's standard DNS path — not through the proxy, not through Private Relay. The result: your real IP ends up in DNS query logs regardless of what your privacy settings say.
WebAuthn Related Origin Requests are the most exploitable of the three. When a site uses WebAuthn — the standard underlying passkeys — the browser needs to fetch a validation file from the server. WebKit hands this off to the operating system's credential service, which makes the request directly from the device, outside the proxy entirely. Mysk was explicit about what this means: any website that supports passkeys can see your real IP address, without any user interaction, even if you never actually use a passkey. The site simply has to configure WebAuthn in a way that triggers the bypass.
WebTransport is an HTTP/3-based protocol designed for low-latency bidirectional data. When WebKit opens a WebTransport connection, it goes direct — bypassing the proxy and exposing the device's real IP.
The research team has a proof-of-concept at leaks.psylo[.]app that lets anyone see which of these apply to their device and browser. Running it with Private Relay enabled is illuminating.
## The Passkey Problem Is Different
DNS prefetching leaks are annoying and worth fixing, but they require the resolver to be paying attention and correlating data points. Most passive observers aren't doing that in real time.
The WebAuthn bypass is different in character. Mysk described it precisely: the website has to deliberately exploit it. That's not a passive information leak — it's an active deanonymization capability that any site claiming to support passkeys can use against a visiting user.
Think about what this means for adoption. Apple has pushed passkeys aggressively across iOS and macOS as a phishing-resistant replacement for passwords. The pitch to users is: passkeys are more secure AND more private because there's no shared secret to steal. But the underlying implementation hands any passkey-supporting site a method to strip away the proxy privacy layer without the user doing anything at all.
A user who turns on Private Relay specifically because they're logging into something sensitive — a healthcare portal, a legal resource, a site where their real location or identity carries risk — can be deanonymized simply because that site has a WebAuthn configuration that triggers the bypass. No passkey interaction required.
## This Has Happened Before
Private Relay launched with iOS 15 in 2021. Within months, FingerprintJS documented a WebRTC-based mechanism that leaked real client IPs. WebRTC establishes peer-to-peer media connections and historically has been a reliable privacy leak on browsers that don't route it through proxies.
Apple fixed the WebRTC issue. Five years later, three new bypasses are documented in the same feature. The pattern here isn't a one-time oversight — it's a recurring gap between what a privacy feature promises at the feature layer and what the underlying engine actually does.
WebKit is a sprawling codebase. Every new protocol it supports, every new browser API it implements, is a potential new way for traffic to leave the device on a path that wasn't accounted for in the proxy architecture. DNS prefetching, WebTransport, and WebAuthn didn't exist in their current forms when Private Relay was designed. Each one is a reasonable feature in isolation. Together, they represent what happens when you build a privacy guarantee on top of a platform that keeps growing new exit paths.
Apple has told 404 Media it's investigating. As of publication, no timeline for fixes has been provided.
---
## HackWire Analysis
The real story here isn't just three bugs — it's an architectural accountability problem that Apple hasn't fully reckoned with.
Private Relay's design is elegant: two hops, no single point of surveillance. But that architecture only holds if every component of the browser engine respects the proxy abstraction. The more WebKit grows — new protocols, new APIs, new OS-level integrations like passkey credential services — the more surface area exists for traffic to escape that abstraction.
Apple's iOS app store rules force every browser into WebKit. That's usually framed as a competitive issue. It's also a security issue: every WebKit bypass is a universal iOS bypass. There's no alternative engine path for users or vendors to retreat to. When Firefox or Chrome on iOS ship with the WebAuthn bypass, their users have no recourse — they're running WebKit whether they know it or not.
The WebAuthn angle deserves more attention than it's getting. Security coverage of this story has focused on the technical mechanisms, but the deliberate-exploitation framing is significant. This isn't ambient leakage from background browser behavior. A site can target Private Relay users specifically and strip their IP masking on purpose, as part of a session. That's closer to an active attack capability than a side-channel.
For defenders: if your threat model includes location or identity protection for users — journalists, activists, employees with restrictive browsing policies, healthcare contexts where location data is sensitive — iCloud Private Relay should not be treated as a complete solution right now. A real VPN that routes DNS and all traffic through a controlled exit is a different guarantee, though VPN providers have their own trust considerations. The researchers note that VPN connections mitigate the leaks documented here, which is worth communicating to anyone relying solely on Private Relay.
For Apple: this is the second significant Private Relay issue in five years, and it follows last month's Hide My Email unmasking bug. The privacy feature layer needs systematic audit every time WebKit gains a new network capability — not reactive investigation after researchers file.
— HackWire Editorial
---
## Related Coverage