Apple’s Private Relay Can Leak Real IP Addresses: What Privacy Professionals Should Learn 2026
Apple has built much of its privacy reputation around limiting tracking and reducing the amount of information that websites, advertisers and network providers can learn about users. Recent security research, however, shows why privacy professionals should never treat a technical privacy feature as an absolute guarantee.
Researchers Talal Haj Bakry and Tommy Mysk discovered several weaknesses in Apple’s WebKit browser engine that can cause a device’s real IP address or DNS information to become visible even when privacy tools such as iCloud Private Relay are enabled.
What is iCloud Private Relay?
Private Relay is available to iCloud+ subscribers and is designed primarily to protect Safari browsing. Normally, an internet service provider may see a user’s IP address and DNS information, while websites can see the IP address connecting to them.
Apple attempts to separate this information through two relays. The first relay, operated by Apple, knows the user’s IP address but not the website being requested. A second relay, operated by a third-party provider, receives the website request and assigns the user a temporary IP address. The idea is that no single party can easily connect a person’s identity with their browsing activity.
The researchers found that certain WebKit functions can bypass this normal route.
Three mechanisms were identified: DNS prefetching, WebAuthn Related Origin Requests and WebTransport. In some circumstances, these functions communicate directly from the device instead of through the configured proxy. WebAuthn and WebTransport can therefore expose the device’s actual IP address, while DNS prefetching can reveal information about the user’s real network and DNS resolver.
Importantly, the researchers state that these particular weaknesses do not affect traditional system-level VPNs in the same way, because a VPN routes the device’s network traffic at a different level. That does not mean VPNs provide complete anonymity; it simply illustrates that different privacy-enhancing technologies have different architectures and threat models.
Why should privacy students care?
For CIPP/E and other privacy students, the case provides a useful practical example of several core privacy concepts.
First, an IP address can constitute personal data. GDPR Recital 30 specifically identifies Internet Protocol addresses as examples of online identifiers that may leave traces which can be used, particularly when combined with other information, to create profiles and identify individuals.
Second, the case demonstrates the importance of data protection by design and by default. Article 25 GDPR requires appropriate technical and organisational measures to integrate data-protection principles and safeguards into processing activities. A privacy feature therefore needs to be evaluated not only according to what it promises, but according to how the entire technical architecture behaves in practice.
Finally, this is a useful reminder that privacy is not the same as anonymity. Masking an IP address reduces a particular form of identifiability, but other identifiers, browser characteristics, account data and behavioural information may still allow users to be distinguished or profiled.
For future privacy professionals, that may be the most important lesson: privacy-enhancing technologies are valuable safeguards, but they should always be assessed according to their real technical limitations, not simply their marketing claims.
