IP and DNS Leaks in WebKit Affecting Proxy Browsers and iCloud Private Relay
mysk.blog178 points by lapcat 2 days ago
178 points by lapcat 2 days ago
When I go to https://leaks.psylo.app on "Possible IP leaks" side I see only "WebAuthn" with my real IP and, occasionally, WebTransport with an incorrect IP. For "HTTPS Traffic" it always show some other relay. Using Safari 26.5
I'm not sure what would I use WebAuthn for, if ever, maybe I could disable it through "Feature Flags" menu?; regardless, I never treat Apple's services as "premium", since the email fingerprinting thing. I pay mainly for Hide My Email, just to organise things per domain, and it's cheap.
Webauthn is the api for Passkeys and things.
So WebAuthn leaks real IPs, who would have thought!
Tommy Mysk, Talal Haj Bakry: how long did you wait after informing Apple of their incompetence before this public disclosure, please?
Thank you for uncovering this and for the website proving the bug.
We didn't inform Apple at all. The reason why we didn't is explained here:
https://x.com/mysk_co/status/2085026605529768261
Glad you found the website helpful. Thank you.
Understood, thank you, sad Apple has done enough to lose the trust of experts such as yourselves.
Reading your comment and this 404 piece, perhaps you informed them in the minutes* before disclosure and got some kind of approval? (But essentially that wasn’t really informing them ahead of time, simplified in your comment… or I’m thick somehow, hehe well I can be!)
“We have already informed them. They said the issue was ‘dire,’ but they let us disclose the issue. They didn't provide any time when they will address this,” Mysk said.
*Edit: or informed after and “let us disclose” meant they didn’t demand retraction
Many reporters got this comment wrong. "Them" in “We have already informed [them]" refers to the Tor Project team, not Apple. We didn't inform Apple at all. We filed a bug report with Apple soon after we had published the blog to let them [Apple] know.
Apple private relay is very flawed but on the other hand most sites that view connections originating from VPN as suspicious seem to be ok with Apple Private Relay. If you have VPN on your router private relay on top of it could be a good way to do ip address laundering.
I find it pretty annoying that iCloud Private Relay does not work together with VPNs.
I mainly use VPNs to access bank sites (or other sites that are annoying enough to use IP country as a proxy for traffic being evil/legitimate) when traveling, but I often forget to turn off the VPN afterwards, and then spend the rest of my day browsing from my home IP (that terminates the VPN), which would have been hidden behind Private Relay if I'd actually been browsing from my home Wi-Fi.
Cross-site/app ad targeting getting creepy good despite using different browser profiles for work/personal browsing etc. is usually a good tell (at least on IPv6).
There was at least one other Private Relay issue that doesn’t seem to have received much public attention.
I found and reported an IP leak to Apple in December 2025. The issue was caused by an EDNS Client Subnet (ECS) configuration problem in Akamai’s infrastructure, which could result in the client’s real IP being forwarded when it shouldn’t have been.
Apple confirmed the fix at the end of March 2026, and then I unexpectedly received a $5,000 Security Bounty in July.
https://psylo.app/legal/privacy/
Lots of these seem unnecessary, especially collecting "bandwidth usage" and "timestamps".
I love iCloud private relay, but I need a way to turn it off. A command line utility would be amazing, along with the ability to turn off/on DNS-over-HTTP.
You can turn if off in settings > iCloud. Either temporary for a day and auto back on, or permanently until you turn it back on.
Yep, but one cannot script that, make it a part of a bash or automator actions, which is a problem.
There's a PLIST entry possibly relevant to it in `~/Library/Preferences/com.apple.networkserviceproxy.plist`
I couldn't figure out how to get any changes to reflect but maybe it's a good pointer towards a solution?
EDIT: Reading into this, looks like they're very intentional about not allowing arbitrary enable/disable calls to it, likely to prevent a hostile entity from switching it off on unsuspecting users. The systems setting calls an XPC into a daemon that makes a web request, then validates the response from the API to update the PLIST structure.
> hostile entity from switching it off on unsuspecting users
I agree it's likely to prevent third parties from messing with the setting, but not hostile third parties specifically. Think of a VPN app or file sharing browser extensions who might want to disable the relay "to be helpful".
Because a truly hostile entity capable of changing local settings can already obtain the device's real IP and also capture traffic, the two things private relay is meant to prevent. There would be no point. If anything it might increase the odds of detection.
Apple often plays a game where they blend security and business interests, but represent it only as a security interest.
They own the OS and could do for private relay like what they do for screen recording: when it's in use, overlay an unhideable visual indicator that it's that it's in use. Make it visually obvious when it turns off.
Have you tried recording UI events in Automator and saving it as an Application? Then you could execute the .app via script. I haven't done this but in theory it should work.
Thank you for this report. My real IP on my phone was constantly leaking and I knew that WebKit was a culprit. However, I doubt that this was an accident. This is a backdoor that Apple planted.
[flagged]
[flagged]
[dead]
[dead]
Weird advertising on site: "Psylo is our privacy-first browser for iOS and iPadOS"
Correct me if I'm wrong but doesn't Apple disallow any actual 3rd party browser engines? Like, any browser on iOS that isn't the standard safari is just a skin on top of webkit/safari. It doesn't exactly inspire confidence that some third party browser will be able to implement things any better (as compared to like, running Firefox on Android, which actually implements the firefox browser engine).
My read is that the main value prop is that they configure the WKWebView to not share any state cross-tabs. In the post they state that they've disabled DNS prefetch, WebTransport and WebAuthn so obviously they're hardening beyond what ships in Safari (though some of this may already be covered by lockdown mode).
Networking is not handled by the rendering engine, which is an only a part of a browser app. That’s a credible claim.
Networking is very core to webkit of course. But it has apis to block and modify requests.
But WKWebView does handle its own networking. You’re able to implement block lists, just the same as you can via browser plugin, but in this instance networking definitely is handled by WebKit.
Networking is handled by WebKit but based on the article it looks like the app configures itself as a HTTP proxy for WebKit and uses that to handle networking.