On August 4, 2026, Mysk researchers published an analysis of three WebKit mechanisms that route traffic around a configured proxyâdirectly from the device. All iOS browsers with proxy mode were affected, including Tor browsers, as well as Apple's own serviceâiCloud Private Relay. The proxy is enabled, the interface shows a foreign country, yet the site sees your real IP and your home DNS resolver.
This is not an exotic vulnerability for the paranoid. It is a clear demonstration of an architectural rule that everyone working through a proxy should understand: an application-level proxy only protects the traffic that passes through the network stack of that application. Everything generated by the operating system or a separate system service goes around it.
What Exactly is Leaking
The investigation began with a common scenario: a user of the proxy browser Psylo complained to the developer about a DNS leak. The analysis of the complaint uncovered three independent leak channelsâall of which lie within WebKit itself, not in a specific application.
1. DNS prefetching â the simplest and most troubling
Mechanism: the <link rel="dns-prefetch"> tag asks the browser to resolve the host name in advance to speed up future loading. The problem is that WebKit on iOS resolves such names through the device's regular DNS path, not through the proxy.
Desktop Safari has supported dns-prefetch since Safari 5, but iOS ignored this tagâuntil iOS 26.0 (September 2025). At that time, WebKit enabled it as part of the same change that removed the old implicit speculative DNS prefetching (bug 285744).
How it is exploited: a page embeds unique host names for each visitor in such tags and then simply observes how requests come to its own authoritative DNS serverâfrom the visitor's real network address. No JavaScript, no user interaction. Just opening the page is enough.
2. WebAuthn Related Origin Requests â leak through passkey
This channel appeared back in iOS 18.0. When a site requests WebAuthn credentials (i.e., passkey), the system checks the file https://<rpId>/.well-known/webauthnâto ensure that the domain is indeed associated with the specified relying party.
The key detail: this verification request does not come from the browser's network stack. It is executed by the operating system's credential service, which sends an HTTPS request directly from the device. The proxy configured within the browser simply does not know about it (bug 268426).
This means that it is enough for the page to initiate a passkey requestâand the attacker's server receives a connection from your real IP.
3. WebTransport â QUIC directly from the device
The most recent channel. The call new WebTransport(url) opens a QUIC connection directly from the device, bypassing the proxy configuration. WebTransport in WebKit had long been disabled and was publicly introduced in iOS 26.4 in March 2026 (bugs 260810 and 303453).
Who is Affected
Apple requires all browsers on iPhone to use WebKit. Therefore, every iOS browser that relies on the WebKit proxy API is affectedâincluding all iOS versions of Tor browsers and Psylo, which initiated the investigation. Plus Safari and iCloud Private Relay.
What is not affectedâVPN applications. They operate at the system level and encapsulate all device traffic entirely, including that generated by system services. This is the essence of the difference: a system tunnel has no "bypass." A separate exception is the Onion Browser at Silver security level with Lockdown Mode enabled: it is immune to leaks through WebTransport.
On the developer side, there has already been a response. In Psylo 1.3.1, all three channels have been closed: the application blocks dns-prefetch hints (the page can no longer force the device to resolve names controlled by the attacker), and WebTransport and WebAuthn are disabled by defaultâthese can be enabled selectively with individual toggles. As of the time of publication, Apple is expected to address the issues in a future update; the company has not provided specific timelines.
Why This Has Come to Light Only Now
The timeline here is telling, and it deserves separate examinationâit explains why the problem went unnoticed for so long.
- September 2024, iOS 18.0 â the WebAuthn Related Origin Requests mechanism appears. The leak channel has existed for almost two years and has not been discussed by anyone during this time: domain verification for passkeys appears as a security feature, not as a means to disclose an address.
- September 2025, iOS 26.0 â WebKit enables support for dns-prefetch on mobile devices. Formally, this is a speed optimization; in reality, the page gains the ability to force the device to query arbitrary DNS names bypassing the proxy.
- March 2026, iOS 26.4 â WebTransport is publicly enabled. The third channel.
- August 2026 â a complaint from a single user about a DNS leak leads to an investigation that uncovers all three at once.
The common denominator: none of these features were designed as channels for de-anonymization. All three are standard platform capabilities: speeding up resolution, verifying passkeys, modern transport. They only become leaks when combined with application-level proxy mode, and that is why no one had tested them in this capacity for years.
The practical takeaway is simple and unpleasant: the absence of news about leaks does not mean their absence. You must check yourself regularly, rather than waiting for someone to publish an analysis.
How to Check Yourself
The researchers have provided a public standâleaks.psylo.app. It checks three things: regular HTTPS traffic (what IP and which DNS resolvers the server sees), WebTransport, and the combination of WebAuthn + dns-prefetch. Open it with the proxy enabled and compare the result with the address you expect to see.
It is also worth checking basic hygieneâwhether the IP, DNS, and WebRTC addresses match in your working setup. If you haven't been doing this systematically before, start with our analysis: how to check a proxy for DNS leaks.
Practical Conclusion: Layer Matters
The story with WebKit is a specific case of a general rule that should be kept in mind when working through a proxy, on any platform.
- Browser proxy â device proxy. Configuration within the application covers exactly the traffic that the application itself sends. System services, background processes, updates, push connections, and, as it turns out, the built-in passkey serviceâall of this goes its own way.
- Leaks can occur not only in "known" places. WebRTC has been well-known for a long time, and people have learned to block it. But DNS prefetching and WebAuthn verification are performance and security functions that no one considered as channels for de-anonymization. New browser features regularly create new bypasses.
- Platform updates can silently break your protection. Here, this is literally visible by the dates: DNS prefetching was "enabled" in iOS 26.0, WebTransport in iOS 26.4. The user changed nothing, yet the leak surface grew on its own.
What This Means for Multi-Accounting and Automation
For those who manage multiple accounts or gather data, the risk here is not abstractly private but quite financial. Anti-fraud systems of platforms correlate signals: if a session claims one IP, but an accompanying request comes from another address and from a home resolver, that is a ready reason to link accounts together or flag the session as suspicious.
Practical implications:
- Do not conduct working multi-account sessions in mobile browsers with proxy mode. Until the platform closes the gaps, the application layer on iOS is unreliable by definition.
- Encapsulate traffic at the system level. If the task is specifically a mobile environment, it is wiser to set up a proxy at the device level or route through a separate gateway, rather than relying on configuration within the browser.
- Check the setup after each major OS and browser update. At least once a quarter. Make this part of your checklist, not just "when something goes wrong."
- Disable what you do not use. WebTransport and WebAuthn in a working profile for parsing or SMM are almost certainly unnecessaryâdisabling them removes two leak channels out of three.
The quality of the IP itself remains a separate variable: even with a sealed configuration, a datacenter address reveals itself by ASN. For scenarios where it is important to appear as a regular user, residential proxies work, and for mobile applications and platforms with the strictest anti-fraud measuresâmobile proxies with IPs from real cellular operators. But no class of proxy will save you if part of the traffic physically goes around itâfirst, ensure sealing, then address quality.
Conclusion
The three WebKit bugsâDNS prefetching, WebAuthn Related Origin Requests, and WebTransportâhave shown that "proxy is enabled" and "all traffic goes through the proxy" are two different statements. On iOS, the gap between them turned out to be wide enough for a regular web page without a single line of JavaScript to discover the real address of a Tor browser visitor.
While Apple prepares a fix, the only working strategy is to check, not assume. Open the test stand, compare addresses, disable unnecessary APIs. And treat every major OS update as an event after which the configuration needs to be rechecked. The difference between privacy and its illusion often comes down to one unasked question: "is all traffic really going through?" It is also useful to understand what other signals reveal you beyond the addressâabout which we wrote in our article on protection against browser fingerprinting.