Gaping Security Hole [LWN.net]

Gaping Security Hole

Posted Apr 21, 2026 16:39 UTC (Tue) by clugstj (subscriber, #4020)
Parent article: Firefox 150 released

Why were web sites ever able to access your local network without your permission? This seems like it was always a bad idea.

to post comments

Gaping Security Hole

Posted Apr 21, 2026 17:11 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

Back in the days of yore, when browsers were new and NAT didn't yet exist at any significant scale, the difference between the local network and the Internet was just that your local network was things like 129.234.235.236 (a Durham University IP from the UK), while the website you wanted to visit was in a different netblock (e.g. 193.60.80.100, an IP at Cambridge University). There was no good way for a browser to know that someone on 129.234.235.236/24 considered 129.234.0.0/16 as "local", and everything else as "remote", so browsers allowed you to make HTTP requests to any IP address.

Further, the attackers of that era didn't know the difference either - you could make educated guesses, but you would not know whether 129.234.235.236 is inside the Durham firewall, and has access to 129.234.1.2 that you don't, or whether the Durham firewall treats 129.234.235.236 as dangerous, too.

This has changed - it's now a good guess on an attacker's part that 192.168.1.254 has your home router management interface if you're using BT Broadband, for example. Thus, the threat model is different, because you think of 192.168.1.254 as "private and protected", whereas in the days of yore, 129.234.1.2 was always thought of as publicly addressable.

Gaping Security Hole

Posted Apr 21, 2026 17:52 UTC (Tue) by ballombe (subscriber, #9523) [Link]

Back in the days of yore, there was no javascript and much less option to mess with your local network.

Gaping Security Hole

Posted Apr 21, 2026 17:31 UTC (Tue) by zwol (guest, #126152) [Link] (3 responses)

Indeed, it always was a bad idea! There were reports of active exploitation of this misfeature almost twenty years ago.

<https://bugzilla.mozilla.org/show_bug.cgi?id=354493> and <https://wicg.github.io/local-network-access/> have the gory details of why this took so long to fix; apparently it's harder than you'd think to draw a clear distinction between private and global IP space, and also there are a lot of home gadget manufacturers that relied on the misfeature to let people configure their gadgets via the manufacturer's website.

Gaping Security Hole

Posted Apr 21, 2026 20:16 UTC (Tue) by iabervon (subscriber, #722) [Link] (1 responses)

The other case I know of is allowing local applications to authenticate to remote services by going through browser-based authentication to get the necessary token. The local application presents an HTTP interface on localhost in order to interact with the browser, and it and the authentication site do the appropriate non-same-site handoffs, but that means the authentication site has to redirect back to the local application's HTTP interface.

It seems likely to me that the local application (as well as things like printers) ought to be able to tell the browser when linking to a remote site that the particular remote site ought to be permitted to link back.

Gaping Security Hole

Posted Apr 21, 2026 21:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Pretty much all these kinds of flows now use polling. The CLI application just polls the server periodically (or uses long polling, or HTTP2 events, or whatever) instead of waiting for the browser's local callback.

Gaping Security Hole

Posted Apr 22, 2026 8:14 UTC (Wed) by cortana (subscriber, #24596) [Link]

If my quick reading of the spec is correct, it seems that browsers will assume that private IP address space is 'local' and public space is 'public'. There are networks where this does not hold. I hope browsers will allow the configuration of a list of CIDR ranges to be considered 'local' in addition to the defaults.