A long-standing security vulnerability has been addressed in virtually all web browsers: Chromium-based browsers including Microsoft Edge and Google Chrome, WebKit browsers like Apple’s Safari, and Mozilla’s Firefox.

It can be – and reportedly has been – abused by criminals to gain access to software services they shouldn’t have access to. It affects the aforementioned browsers on macOS and Linux – and possibly others – but certainly not on Windows.

A company called Oligo Security flagged the vulnerability this month, calling it 0.0.0.0 Day because it affects the 0.0.0.0 IPv4 address. And it appears attackers have been exploiting the flaw since the late 2000s – judging by this Mozilla Bugzilla thread from back then, which is still listed as open.

According to Oligo, the teams from the three browsers have promised to block all access to 0.0.0.0 and also take their own measures to close the localhost vulnerability.

The problem is as simple as this: if you open a malicious web page in a vulnerable browser on a vulnerable operating system, that page can fire off requests to 0.0.0.0 and a port of your choosing. And if you have servers or other services running locally on your box on that port, those requests will go there.

So if you have a service running on port 11223 on your macOS or Linux workstation, and you assume that no one can reach it because it’s behind your firewall, and that your well-known browser is blocking external requests to localhost, you’d be wrong. That browser will actually forward a 0.0.0.0:11223 request from a malicious page you’re visiting to your service.

It’s a bit of a gamble, in terms of practical exploitation – but you don’t want to find out the hard way that a site has accidentally hit your local endpoint. It’s even ironically funny that this is still the case in 2024.

There should be security mechanisms in place to prevent external websites from reaching your localhost in this way. In particular, the Cross-Origin Resource Sharing (CORS) specification and the more recent Private Network Access (PNA), which is used by browsers to distinguish between public and non-public networks, and enforce CORS by restricting the ability of external sites to communicate with servers on private networks and host machines.

However, the Oligo team was able to bypass PNA. The researchers set up a dummy HTTP server running on 127.0.0.1, also known as localhost, on port 8080, and were then able to access it from a remote public site using JavaScript, sending a request to 0.0.0.0:8080.

“This means that public websites can access any open port on your host without being able to see the response,” said Avi Lumelsky, security researcher at Oligo.

In response, Chrome will block access to 0.0.0.0 starting in Chromium 128. Google will roll out this change gradually until it is complete in Chrome 133. Apple has made changes to its open-source WebKit software that block access to 0.0.0.0.

Mozilla has no immediate fix and has not implemented PNA in Firefox. According to Olgio, Mozilla did change the Fetch specification (RFC) to block 0.0.0.0 after the report.

A Mozilla spokesperson sent The register the following statement via email:

According to Oligo, this research is a strong argument for PNA.

“Until PNA is fully deployed, public websites can send HTTP requests using JavaScript to successfully reach services on the local network,” Lumelsky wrote. “To change that, we need to standardize PNA and have browsers implement PNA according to that standard.” ®