What happened
On 6 August 2026, TechRadar reported research by Talal Haj Bakry and Tommy Mysk showing that three WebKit features can bypass Private Relay’s proxy configuration and send traffic directly from an Apple device. A destination receiving that direct connection can observe the device’s real public IP address rather than the temporary relay address described in Apple’s documentation. The reporting also identifies Onion Browser as affected by the underlying WebKit behaviour.
One named path is WebTransport, which opens a direct HTTP/3 connection instead of using the configured relay. WebTransport has been available since iOS 18.0, according to the cited reporting. Apple describes Private Relay as a two-relay service intended to prevent one party from seeing both the user’s identity and browsing destination, and says the destination should receive a temporary address rather than the original client IP.
The cited reporting did not publish a complete affected-version matrix, CVE identifier or Apple patch reference. It also did not establish active malicious exploitation or identify websites collecting exposed addresses. Attribution posture: The cited research describes a privacy-control bypass and establishes no threat actor or exploitation campaign. Until Apple publishes authoritative remediation, security teams should treat the finding as a reproducible control limitation rather than a confirmed compromise. The cited source did not publish the specific operational detail described as No confirmed malicious exploitation or collection.
Why this matters now
Private Relay is a consumer privacy service, not an enterprise VPN, but the distinction can become blurred in executive-protection guidance, travel procedures and privacy programmes. If users or control owners believe Safari traffic always hides the source IP, a direct WebKit connection creates an undocumented exception with potential location, identity-correlation and operational-security consequences.
The enterprise impact depends on workflow. Many users face limited consequence from a destination learning their public address. Risk is higher for executives, investigators, journalists, regulated personnel, incident responders and travellers whose source network or location may reveal identity, jurisdiction, employer or sensitive activity. It also matters where policy decisions depend on the apparent egress location.
The absence of authoritative affected versions prevents fleet owners from answering a simple remediation question. Teams therefore need a bounded test, a list of workflows requiring source concealment and a compensating control that is managed, monitored and supportable. Blanket disabling of Private Relay may reduce privacy without fixing the underlying need.
The decision for security leaders
Remove Private Relay from any enterprise statement that represents it as guaranteed IP concealment, full-tunnel protection or an approved replacement for managed remote access. Privacy and endpoint teams should document its intended scope and the traffic classes that are outside their assurance evidence.
Test the reported WebTransport behaviour on representative managed devices and networks. Capture both client-side and destination-observed addresses while Private Relay is enabled. Testing should distinguish Safari browsing, WebTransport and traffic routed through any managed VPN or zero-trust access service.
Assign compensating protection by user and workflow rather than issuing a generic fleet-wide response. Where source-IP exposure creates material risk, require a managed tunnel with enforceable routing, health telemetry and an identified owner. Time-bound the exception until Apple publishes a version matrix or fix.
Evidence of closure
- Packet captures show no client-IP exposure for workflows requiring source concealment.
- Policy records remove Private Relay from approved enterprise-control claims.
- Managed VPN logs confirm protected traffic uses enforced enterprise egress.
- Risk acceptance identifies affected users, scope, owner and expiry.
The Security.io assessment
This is a control-assurance issue with developing evidence, not a demonstrated enterprise breach. The researchers’ finding is technically plausible and specific, while Apple’s documentation provides a clear baseline for the expected relay behaviour. Apple had not published a CVE, affected-version list or remediation in the cited sources at publication time.
The finding should not be overstated into a claim that all Private Relay traffic leaks or that every Apple user is exposed to the same consequence. The report identifies three WebKit paths and names WebTransport as one direct HTTP/3 route. Impact depends on whether a user encounters the relevant web functionality and whether source-address concealment is material to the workflow.
The larger governance lesson is durable: consumer privacy features should not silently become enterprise controls. If the organisation depends on hiding source identity or location, it needs test evidence, managed routing and an owner for exceptions. Private Relay may remain useful privacy protection, but it should not carry an assurance claim its operators cannot verify.
Questions for the morning meeting
- Where is Private Relay represented as equivalent to a managed VPN?
- Which users face material harm if a destination learns their real IP address?
- Can endpoint and network teams reproduce the reported WebTransport path?
- Who owns temporary risk until Apple publishes remediation guidance?