Diving into 0.0.0.0 Day: How the “Zero” IP Address Can Hack Your Local Network
Security experts at Oligo Security recently disclosed the “0.0.0.0 Day” vulnerability, which allows malicious websites to bypass browser protections and interact with services running on an organization’s local network. This can potentially lead to unauthorized access and remote code execution. The issue arises from inconsistent security implementations across browsers and a lack of industry-wide standardization. As a result, the seemingly harmless IP address 0.0.0.0 can become a powerful tool for attackers to exploit local services, including those used for development, operating systems, and even internal networks.
The impact of 0.0.0.0 Day is far-reaching, affecting both individuals and organizations. The discovery of active exploitation campaigns (discussed below) highlights the urgency of addressing this vulnerability.
Critical Vulnerability Affects All Major Browsers
This vulnerability affects all major web browsers (Chromium, Firefox, Safari) and allows attackers to compromise local networks. 0.0.0.0 Day emerged due to how browsers handle network requests, potentially giving hackers access to sensitive services running on local devices.
The logical flaw allows external sites to interact with software running locally on MacOS and Linux (localhost), and potentially execute arbitrary code on the visitor’s host by using 0.0.0.0 instead of localhost/127.0.0.1. Windows is not affected by this issue.
Fixes in Progress: Browsers to Block 0.0.0.0
After responsible disclosure, HTTP requests to 0.0.0.0 are now being added to security standards via a Request for Comments (RFC), and some browsers will soon fully block access to 0.0.0.0. The address will no longer be allowed as a target IP in the Fetch specification, which defines how browsers should handle HTTP requests.
In early April 2024, Oligo reported the vulnerabilities to the security teams responsible for each major browser. Each company acknowledged the issue and will work to update the relevant standards and implement browser-level mitigations.
Ultimately, all browsers will block 0.0.0.0, but the market also demands a unified standard. The lack of a final standard has led to different implementations across browsers, meaning each browser currently handles HTTP requests to internal or local networks differently.
Browser Fixes:
- Google Chrome (and Chromium-based browsers, including Edge): 0.0.0.0 Day bypassed the Private Network Access (PNA) mechanism in Chromium, which blocks websites from accessing 127.0.0.1, localhost, and other private IPs via JavaScript when loaded from public websites. After Oligo Security’s report, Chrome is blocking access to 0.0.0.0 (Finch Rollout) starting with Chromium 128. Google will gradually roll out the change, completing it by Chrome 133, after which the IP will be fully blocked for all Chrome and Chromium users.
Notably, the percentage of websites communicating with 0.0.0.0 is growing, according to Chromium counters. Such pages may be malicious, and currently, the percentage is 0.015% of all websites. With 200 million sites worldwide (as of August 2024), about 100,000 public sites may communicate with 0.0.0.0. - Apple Safari: Apple browsers are based on the WebKit engine. After Oligo Security’s report, Apple updated WebKit to block access to 0.0.0.0. The company added a check for the destination host’s IP address; if it’s all zeros, the request is blocked.
- Mozilla Firefox: As of now, Firefox has no fix. While a fix is in progress, Firefox never restricted Private Network Access (PNA), so technically, PNA was always allowed. From this perspective, “there’s nothing to fix” since PNA was never implemented in Firefox. After Oligo Security’s report, Mozilla updated the Fetch specification (RFC) to block 0.0.0.0. Firefox has prioritized implementing PNA, though it is not yet in place. In the future, Firefox will block 0.0.0.0 regardless of PNA implementation.
0.0.0.0 Day: A Deeper Dive
We all have a favorite browser and use it daily. Even non-browser apps often load resources from external domains, such as Google Analytics or embedded scripts and videos.
Developers have always implemented innovative security concepts in browsers, like sandboxing, HTTPS-only cookies, and CORS (Cross-Origin Resource Sharing) to protect servers and end users. These protections keep malicious sites using CSRF attacks away from users’ personal data, internal networks, and local apps.
Browsers can send requests to almost any HTTP server via JavaScript. When handling cross-site responses, browser security mechanisms decide what action to take:
- Valid: Pass the response data to the JavaScript context.
- Invalid: Return a masked response or trigger a special error (CORS, SOP, etc.).
But sometimes, the response doesn’t matter. With the 0.0.0.0 Day vulnerability, a single request can be enough to cause harm. Before diving into the details, let’s cover some background.
The Most Unusual IP: What Is 0.0.0.0?
Let’s go back to the root of the problem: 0.0.0.0 can be used in several ways. You might already think of uses like “all IP addresses on the host,” “all network interfaces,” or simply “localhost.”
RFC 1122 references 0.0.0.0 as {0,0}:
- RFC 1122 forbids using 0.0.0.0 as a destination address in IPv4 and allows it as a source address only in specific cases, such as in a DHCPDISCOVER packet during DHCP handshake when an IP is assigned for the first time.
- 0.0.0.0 is sometimes used in /etc/hosts files to block certain domains (acting as an ad blocker) or, in network policies, the CIDR block 0.0.0.0/32 means all IPs are allowed.
Why Is a Site Scanning My Ports?
Fingerprinting website users is a well-known technique with many purposes. The most common legitimate use is identifying returning users, but attackers can also use it to gather intelligence for phishing campaigns. Sites can learn a lot about who is visiting, even if you’ve never logged in.
In 2020, it was discovered that eBay tried to scan visitor ports right after the site loaded. The site used JavaScript to scan ports on localhost (127.0.0.1), creating a unique fingerprint. Since the scan happens in the browser, user firewalls can’t prevent it.
Browsers shouldn’t be able to send such requests, as a single request can lead to exploitation. The internet worked this way for years, and no one cared. It took time to realize this behavior could lead to violations, and by then, it was part of every browser, making it hard to fix.
An 18-Year-Old Bug
Local and internal services have always been a prime target for attacks. In 2006, Mozilla reported an interesting security issue discovered before Chrome’s first release in 2008. Notably, the 18-year-old bug report is still open.
The report claimed that public sites attacked the user’s router on the internal network and argued that sites shouldn’t be able to do this. At the time, internal networks (and the internet in general) were inherently insecure: many services lacked authentication, let alone SSL certificates and HTTPS, which weren’t everywhere. Websites loaded over unsecured HTTP, and attackers constantly abused browsers for malicious purposes.
Since 2006, hackers have exploited the fact that requests are still sent while browsers focus on responses. For example, using malicious JavaScript on an attacker-controlled site, a cybercriminal could change the configuration of a victim’s home or office router.
After 18 years, hundreds of comments, and several reclassifications (from “serious” to “critical”), the bug remains open. In June 2023, Google security expert David Adrian reported several cases of 0.0.0.0 Day exploitation.
Maintainers struggled to agree on the nature of the bug — is it a “vulnerability,” does it only affect Firefox, or is it a feature request? Some Firefox developers argued it was neither a bug nor a feature. Nevertheless, the bug report will remain open until Firefox implements PNA.
Triggering the bug required just one HTTP request — the response didn’t matter. Malicious script examples were documented as early as 2006 in attacks on home routers.
The lack of standardization was the main source of all these issues, creating a clear need for a basic security mechanism in all browsers. The world needed a standard to extend Cross-Origin Resource Sharing (CORS) across all major browsers, allowing them to distinguish between local, private, and public networks. Google boldly filled this gap by introducing Private Network Access (PNA).
What Is PNA (Private Network Access)?
For a long time, it was unclear how browsers should behave when making requests to local or internal networks from less private contexts. Domains like attacker.com should never be able to contact localhost in any real scenario.
All major browsers relied on CORS. CORS helps, but its effectiveness depends on the response content, so requests are still created and sent. History has shown that a single HTTP request can attack a home router — and if that’s all it takes, every user should be able to prevent such requests.
PNA extends CORS by restricting websites from sending requests to servers in private networks. PNA distinguishes between public, private, and local networks. Pages loaded in less secure contexts can’t interact with more secure ones. For example, attacker.com can’t contact 127.0.0.1 or 192.168.1.1, as these IPs are considered more private. The diagram below shows the relationship between public, private, and local networks in PNA.
How Is PNA Different from CORS?
While CORS protects unintended content only from being loaded in unsafe contexts (at the response level), PNA strengthens this by providing a chance to prevent the request from being sent at all.
Testing 0.0.0.0: Bypassing PNA
According to the current PNA specification, the following IP segments are considered private or local:
- 127.0.0.1/8 (localhost)
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- 169.254.0.0/16 (link-local)
During research, it was found that 0.0.0.0 is not on the list. Oligo Security experts believed that as part of PNA, sites couldn’t send requests to 0.0.0.0. According to the spec, 0.0.0.0 shouldn’t be used as a target.
To test this, researchers ran a dummy HTTP server on localhost (127.0.0.1), then tried to access it from an external domain via JavaScript using 0.0.0.0.
The result: the request reached the server.
- On a public domain (.com), the browser sent a request to 0.0.0.0.
- The dummy server was listening on 127.0.0.1 (loopback interface only, not all network interfaces).
- The server on localhost received the request, processed it, and sent a response.
- The browser blocked the response content from reaching JavaScript due to CORS.
In other words, public sites can access any open port on your host, without seeing the response. This is a bypass of the current PNA implementation and a fundamental browser flaw. The researchers reported their findings to all browser vendors as part of responsible disclosure. However, a real threat and attack vector were needed to prove the concept.
Finding Vulnerable Local Applications
To exploit 0.0.0.0 Day, you need an application that could be affected — and there are plenty. When services use localhost, they assume a restricted environment. This assumption, which can be wrong (as with 0.0.0.0 Day), leads to insecure server implementations. For example, many apps skip CSRF token checks and compromise authorization or authentication, since they expect to run in a tightly controlled network environment.
In some cases, there may be no authorization or authentication, or no CSRF token checks. When an app detects it’s running in a secure or trusted isolated network, it allows POST HTTP routing without authorization or CSRF tokens, as well as write access to resources and configs, enabling code execution. Even a single HTTP request can grant access to your ports.
To find a local app vulnerable to browser-based attack, you first need an HTTP server running on a local port (localhost interface). To achieve remote code execution, the service must have HTTP routing that can write, configure, or modify files and settings.
Apps have many endpoints, and local services often compromise on security, which is great news for attackers. Researchers focused on the vulnerable Ray framework.
ShadowRay from the Browser
Oligo experts based their work on the ShadowRay campaign discovered in March, which targets AI compute resources. The vulnerability allowed hackers to exploit unprotected environments. Oligo proved that such an attack can be launched from the browser using 0.0.0.0 as the attack vector.
First, in the right terminal, a local Ray cluster is started on localhost. Then, in the left terminal, a socket listens for new connections to open a reverse shell. The victim clicks a link in a phishing email, triggering the exploit. The exploit opens a reverse shell on the victim’s machine. Here is an example of the exploit code:
// Example exploit code omitted for brevity
How the attack works in different browsers:
- Google Chrome
- Apple Safari
- Mozilla Firefox
Launching ShadowRay from the browser is just one of many remote code execution (RCE) attacks possible with this approach. Here are a few more attack vectors using 0.0.0.0 Day:
Selenium Grid
In a recent SeleniumGreed campaign, attackers used public Selenium Grid servers to gain initial access to organizational systems via known RCE vulnerabilities. It was found that on local Selenium Grid instances, RCE is possible by sending a POST request to http://0.0.0.0:4444/ with a crafted payload.
Another interesting attack vector: using a local Selenium Grid cluster to browse sites with unsafe browser configurations to access internal domains and private DNS records behind a VPN.
Pytorch TorchServe (ShellTorch)
In July 2023, Oligo disclosed several new critical ShellTorch vulnerabilities to PyTorch, Amazon, and Meta* developers, leading to remote code execution in PyTorch TorchServe and ultimately giving attackers full server access.
AI specialists using TorchServe on internal networks (locally or with port forwarding) can also be exploited via 0.0.0.0, compromising the local TorchServe cluster behind firewalls and WAFs.
Identifying Returning Users via Open Ports
Another interesting attack vector is identifying anonymous users by scanning ports, even those without cookies who have never logged in. Local port scan results can be cross-checked with additional data like User-Agent, IP address, and other identifiers from fingerprinting services.
Scanning showed that different personas within an organization use the following ports:
- TeamViewer (port 5938)
- Selenium Grid (port 4444)
- Ray (port 8265)
How Local Is Your Localhost?
Until PNA is fully deployed, public websites can send HTTP requests via JavaScript to access services on the local network. To change this, PNA must be standardized, and browsers must implement PNA according to the standard.
CORS is also helpful and already makes the internet much safer. CORS prevents responses from reaching the attacker, so hackers can’t read data from invalid requests. When a request is sent, if CORS headers are missing in the response, malicious JavaScript can’t read the response content. CORS only stops the response from reaching JavaScript, but “opaque” requests can be sent in “no-cors” mode and still reach the server (if the response doesn’t matter).
Oligo Security’s demo proved that by using 0.0.0.0 with “no-cors” mode, cybercriminals can use public domains to attack services running on localhost and even achieve arbitrary code execution with just one HTTP request.
Browsers have now prioritized fixes and made critical changes, blocking 0.0.0.0 as a target IP. It was important to have a coordinated fix to avoid browsers “passing 0days” to each other during patching.
How to Protect Local Apps from 0.0.0.0 Day
Obviously, waiting for a browser fix isn’t the best option, so developers can take steps to protect local apps. Oligo Security experts recommend:
- Implement PNA headers;
- Check the HOST header of requests to localhost or 127.0.0.1 to protect against DNS Rebinding attacks;
- Don’t trust the local network just because it’s “local” — add at least minimal authorization, even on localhost. Jupyter Notebook developers did this well by adding a default token;
- Use HTTPS whenever possible;
- Implement CSRF tokens in your apps, even if they’re local;
- Remember that browsers act as gateways, and many browsers can route to internal IP address spaces.