Full Report
Browsers can request any data via HTTP using JavaScript. From a website, it's possible to make requests to items on the local network, such as localhost. Should this be allowed? IP scanning and attacks on the LAN are very possible here. All major browsers have CORS - but this is only for response data and not the outbound. So, Chrome released a standard called Private Network Access (PNA). This extends CORS to restrict the ability to send requests to PNA domains. PNA has a large list of domains that fall into the private category. While doing research into this topic, they noticed that 0.0.0.0 was not in the list though. Is this bad? 0.0.0.0 has multiple uses but it commonly just means localhost. Since 0.0.0.0 can be requested to, this violates PNA completely for localhost. Many local apps skip CSRF or authentication checks solely because of this feature. They found that an application called Ray used by developers could be exploited for RCE. Selenium Grid had a similar issue as well as PyTorch. How do we fix this? PNA headers will be added to requests. In order to allow the browser to make these requests, the website will need to return Access-Control-Request-Private-Network: true, similar to how CORS works. Good bug write up and a good explanation on an incoming feature!
Analysis Summary
# Vulnerability: 0.0.0.0 Day (Browser PNA Bypass)
## CVE Details
- **CVE ID**: N/A (Broad design flaw across multiple browser engines; specific vendor trackers include Chromium issue 40103681)
- **CVSS Score**: Not officially assigned (Estimated 8.0+ due to potential for RCE)
- **CWE**: CWE-284: Improper Access Control; CWE-352: Cross-Site Request Forgery (CSRF) via IP alias.
## Affected Systems
- **Products**: Major Web Browsers (Chrome/Chromium, Apple Safari/WebKit, Mozilla Firefox local to Linux/macOS).
- **Versions**:
- **Chromium**: Versions prior to 128 (Windows excluded).
- **Safari**: Versions prior to macOS Sequoia / iOS 18.
- **Firefox**: Historically affected; fix in progress via Fetch specification updates.
- **Configurations**: Systems running Linux or macOS where internal applications (e.g., Ray, Selenium, PyTorch) listen on `localhost` or `0.0.0.0` without robust CSRF protection or authentication.
## Vulnerability Description
The "0.0.0.0 Day" exploit leverages a gap in **Private Network Access (PNA)** specifications. While browsers implement CORS and PNA to prevent public websites from reaching private IP ranges (like `127.0.0.1` or `192.168.x.x`), the IP address `0.0.0.0` was historically omitted from these blocklists on Linux and macOS.
On these platforms, `0.0.0.0` often defaults to the local loopback interface. Attackers can use JavaScript on a public website to send malicious requests to `http://0.0.0.0:[port]`. Because internal applications frequently trust local traffic and skip authentication/CSRF checks, this bypass allows external actors to interact with local APIs directly.
## Exploitation
- **Status**: PoC available; actively exploited in the wild (e.g., **ShadowRay** campaign).
- **Complexity**: Low
- **Attack Vector**: Network (Remote via malicious/compromised website).
## Impact
- **Confidentiality**: High (Access to local service data and internal API responses).
- **Integrity**: High (Ability to execute commands or modify local configurations; RCE confirmed on Ray, Selenium Grid, and PyTorch).
- **Availability**: High (Ability to shut down local services or crash development environments).
## Remediation
### Patches
- **Google Chrome/Chromium**: Access to `0.0.0.0` is being blocked starting in version 128, with a full rollout completed by version 133.
- **Apple Safari**: Fixed in WebKit for macOS Sequoia, iOS 18, and related updates for visionOS and iPadOS.
- **Mozilla Firefox**: Implementing blocks in alignment with updated Fetch specifications.
### Workarounds
- **Application Level**: Developers should implement **CSRF tokens** and **Header Checking** (verifying the `Host` header) even for local-only services.
- **Network Level**: Use firewall rules (e.g., `iptables`) to explicitly drop incoming traffic to `0.0.0.0` from external sources.
- **HTTPS**: Transition local services to use HTTPS with valid certificates, as PNA restrictions are stricter for non-secure contexts.
## Detection
- **Indicators of Compromise**:
- Unusual HTTP requests in local application logs originating from unexpected browsers.
- Requests containing the header `Access-Control-Request-Private-Network: true` targeting port-heavy local developer tools.
- **Detection Methods**: Monitor browser console errors for blocked requests to `0.0.0.0` or use network traffic analysis tools (like Wireshark) to identify outbound traffic from the browser to the null IP.
## References
- [Oligo Security Blog Post](https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser)
- [Chromium Status: Block 0.0.0.0](https://chromestatus[.]com/feature/5106143060033536)
- [Apple Security Support](http://support.apple[.]com/en-us/121250)