2056579 - Firefox built-in VPN does not set media.peerconnection.ice.proxy_only while active, so WebRTC STUN over UDP bypasses the proxy and exposes the user's real IP, defeating the feature's stated IP-protection with no user warning

Reporter

Description

•

2 months ago

Attached file webrtc_ip_leak.html — Details

Description

The Firefox built-in VPN (launched Firefox 149, March 2026) is marketed as an IP-protection feature. Mozilla's own descriptions state it "routes your traffic through a proxy server, so websites see a different IP address instead of your real one" (firefox.com) and is "a new IP-protection feature designed to keep you even more private while you browse" (blog.mozilla.org).

The feature is implemented as a browser-layer HTTPS proxy. WebRTC ICE gathering uses STUN requests over UDP, which the HTTPS proxy does not tunnel. As a result, when the built-in VPN is active, WebRTC still reflects the user's real public IP address via a server-reflexive (srflx) ICE candidate, while HTTP(S) traffic correctly shows the proxy exit IP.

The practical effect: a user who enables the built-in VPN believing it masks their IP has their real IP silently exposed to any website that runs a few lines of RTCPeerConnection JavaScript, with no camera/microphone prompt and no warning.

Relationship to bug 959893

I am aware of bug 959893, which covers the general WebRTC IP-exposure mechanism and was resolved as conformant to the RTCWEB spec, with mitigation left to opt-in prefs (media.peerconnection.ice.proxy_only / proxy_only_if_behind_proxy) and mDNS for local addresses.

This report is narrower and concerns the new product, not the engine default. 959893 is about Firefox's default WebRTC behavior for a user who has not configured any proxy. This report is about the built-in VPN feature, when explicitly enabled by the user, failing to activate the pref that already exists to close this exact hole. The user has taken an explicit action (toggling on an "IP-protection" feature) and has a reasonable, Mozilla-stated expectation that their real IP is now masked. The feature does not set proxy_only, so that expectation is silently violated.

In other words: the mechanism is known (959893), but the product-integration decision to ship an IP-protection feature without enabling the available WebRTC mitigation is the issue here.

Steps to reproduce

Enable the Firefox built-in VPN (toolbar VPN icon).
Confirm the proxy is active: visit an IP-check site; it shows the proxy exit IP (ISP "Mozilla Corporation" / Fastly).
On any page, run:

const pc = new RTCPeerConnection({iceServers:[{urls:'stun:stun.l.google.com:19302'}]});
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createDataChannel('x');
pc.createOffer().then(o => pc.setLocalDescription(o));

or

run poc.

Observe the srflx candidate.

Actual results

With the built-in VPN active:

HTTP(S) exit IP (IP-check site): 45.58.232.100 (Mozilla / Fastly proxy exit)
WebRTC srflx candidate: ...(my real ISP public IP, confirmed identical to the IP shown with the VPN disabled)
Host candidates were correctly mDNS-obfuscated (.local), so the local LAN IP did not leak. The issue is specifically the real public IP leaking via the srflx candidate while the VPN is on.

Expected results

When the built-in VPN is active, WebRTC should not expose the real public IP that the feature is masking for all other browser traffic. Enabling the VPN should also constrain WebRTC (for example by setting media.peerconnection.ice.proxy_only, or proxy_only_if_behind_proxy, or otherwise forcing ICE through the proxy / relay-only) so that the real IP is not reflected. If a trade-off with WebRTC functionality is unavoidable, the limitation should at minimum be disclosed to the user when the VPN is enabled, rather than silently leaking.

Impact

The feature's entire stated purpose is masking the user's IP. A user on public Wi-Fi, or a user trying not to link activity across sites (both use cases Mozilla names explicitly in its announcement), can be deanonymized by any site running trivial WebRTC JavaScript, despite having the VPN enabled and believing they are protected. The gap is invisible: there is no prompt, no indicator, and the HTTP-level IP check that a user might perform to "verify" the VPN shows the proxy IP, giving false confidence.

Suggested fix

When the built-in VPN is enabled, set media.peerconnection.ice.proxy_only (or proxy_only_if_behind_proxy) for the duration, so WebRTC ICE is forced through the proxy and the real IP is not gathered as a candidate. This is a small, targeted change scoped to the VPN feature's active state; it does not change default WebRTC behavior for users who are not using the built-in VPN. Alternatively, surface the WebRTC limitation clearly in the VPN UI/support documentation.

Flags: sec-bounty?