Apple WebKit vulnerabilities reveal your IP address, despite Private Relay

Three WebKit mechanisms have been discovered to bypass Apple’s iCloud Private Relay. In fact, the mechanisms can bypass any browser‑level proxy configuration, including Psylo’s proxy, Tor-on-iOS proxy setups, and so on. Private Relay is a VPN-like system for Safari on iOS which is meant to prevent websites from viewing the visitor’s IP address and location. But because all three methods described by the researchers occur outside WebKit’s normal page loading path, Apple’s iCloud Private Relay never sees them and, as a result, means you can’t hide your IP address or Domain Name System (DNS) path in these cases. The three features are: DNS prefetching Modern browsers try to be faster by looking up the IP addresses of links on a page before you click them, a feature known as DNS prefetching. In WebKit, these DNS lookups can bypass the configured proxy/relay and go straight through the system’s normal DNS stack, exposing which DNS servers you are using and, indirectly, where you really are. Even if the actual page load goes through Private Relay, the prefetch DNS queries can still leak metadata about your network. WebAuthn and passkeys WebAuthn (the standard behind passkeys ) sometimes needs to fetch a small file from the website’s domain to verify that the credential is being used on the right site. The researchers found that, on Apple platforms, this fetch is performed outside the usual WebKit page‑loading path, which means it is not sent through the Safari proxy or Private Relay. The result is that a site using passkeys can cause your device to contact it directly, revealing your true IP address even if the rest of your browsing is supposedly hidden behind a relay. WebTransport and related technologies WebTransport is a newer API that gives websites a way to open low‑latency, bidirectional connections to a server. In the scenarios the researchers tested, these WebTransport connections were also initiated outside the proxied WebKit code path, creating another route for sites to receive traffic straight from the device. That traffic again carries the device’s real IP, not the relay or proxy IP the user expects. From a user‑experience point of view, the problem is that all three mechanisms look like normal browser behavior and require no special tricks from a malicious site. What’s affected Affected are Safari on iOS and macOS when Private Relay is used, because Private Relay is implemented as a WebKit‑level proxy that only applies to Safari traffic. Additionally, any iOS/macOS browser or app that relies on WebKit’s proxy configuration to hide the IP (e.g., Psylo, Onion Browser/Tor on iOS, and other proxy browsers), since they all hit the same WebKit behavior. And that’s not necessarily all. For most of iOS’s history, any app that browsed the web had to use Apple’s WebKit framework and JavaScript engine. This meant that Chrome, Firefox, Edge, Brave, and other browsers on iPhone were effectively different shells around the same WebKit engine Safari uses. Under pressure from the EU’s Digital Markets Act (DMA), Japan’s Smartphone Act, and similar regulatory pushes, Apple introduced a mechanism for non‑WebKit engines, but only in constrained ways. Malwarebytes’ Senior manager for iOS software Roman Dvoinev commented: “Basically the API has been “open” for a while, but no browser vendor has actually shipped a non-WebKit browser yet. Major players are still in prototype phase, as Apple’s bar for shipping a browser to iOS is very high.” Malwarebytes VPN is not affected, since it tunnels the device’s entire network traffic at the system level. The researchers have reported the problems to Apple and are expecting patches by fall . Browse like no one’s watching. Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free → About the author Was a Microsoft MVP in consumer security for 12 years running. Can speak four languages. Smells of rich mahogany and leather-bound books.