Browsers are supposed to keep the web away from your local machine. A freshly disclosed "0.0.0.0 day" flaw shows that line is thinner than most people think. Researchers say a malicious site can reach services running on the same device by abusing the address 0.0.0.0, the placeholder normally used for all network interfaces.
The scope is narrower than a headline panic suggests. The issue hits Linux and macOS systems. Windows is not affected. Chrome, Firefox, and Safari have all confirmed the flaw, and patches are rolling out across the next several browser versions.
What happened
- The vulnerability affects Chrome, Firefox, and Safari on Linux and macOS, not Windows.
- It lets public websites send HTTP requests to 0.0.0.0, which routes to local services.
- The bug was first reported 18 years ago and remains unresolved in current builds.
- Chrome will block 0.0.0.0 access starting in version 128, finishing by version 133.
- Firefox has made the related Private Network Access work a top priority.
- Safari will block 0.0.0.0 in WebKit changes shipping with Safari 18.
How the attack works
Browsers normally block cross-site requests to internal addresses using CORS and Private Network Access rules. The 0.0.0.0 address slips past those defenses. A hostile page can craft an HTTP request aimed at 0.0.0.0, the request lands on the local machine, and a vulnerable local service processes it. That service could be a dev server, an admin panel, or any internal app that assumed only trusted software would call it.
The blast radius depends on what is running locally. A developer laptop with a dozen containers open is a richer target than a clean office workstation.
Who should care
| Audience | Risk Level | Immediate Action |
|---|---|---|
| Linux/macOS users browsing with Chrome, Firefox, or Safari | High | Update browsers as patches release; avoid untrusted sites |
| Developers running local services | Critical | Bind to 127.0.0.1; add authentication to internal tools |
| Security teams | Medium | Track browser version rollouts; push patches internally |
| Windows users | None | No action needed for this specific flaw |
Our analysis
The 18-year history is the real story. A flaw reported before Chrome existed is still live in three flagship browsers. Each shipped its own rules for localhost and private ranges, but the shared address 0.0.0.0 stayed in a grey zone that no single vendor owned.
The phased rollout creates a hidden trade-off. Chrome's block spans versions 128 through 133, which means weeks or months of exposure depending on how your fleet updates. Firefox users wait for an unspecified PNA timeline. Safari users wait for Safari 18. During that gap, developers carry the load—they must treat localhost like a public endpoint.
The active exploitation in the wild separates this from theoretical vulnerabilities. When researchers confirm attackers are using something, the "patch this sprint" urgency overrides the "wait for the next release cycle" instinct.
What to watch next
Track your fleet's browser versions. For Chrome, push version 128 or higher as soon as it lands internally. For Firefox, watch release notes for the PNA update. For Safari, plan around the Safari 18 release.
Until patches land, add host header checks, CSRF tokens, and proper permissions on any service that listens locally. The fix is coming—but the window stays open until it arrives.
Key takeaways
- The flaw is real and active, but limited to Linux and macOS, not Windows.
- Browser patches are coming in waves, with Chrome leading a phased rollout through version 133.
- Local services should bind to 127.0.0.1 and require authentication, not rely on browser-only isolation.
Frequently asked questions
Which systems are affected by the 0.0.0.0 day flaw?
Linux and macOS systems running Chrome, Firefox, or Safari. Windows is not affected.
Is the 0.0.0.0 day vulnerability being actively exploited?
Yes. Researchers have confirmed exploitation in the wild, which raises the urgency above a theoretical bug.
When will Chrome block 0.0.0.0?
Google is rolling out the block across Chrome versions 128 through 133.
What should developers do before patches land?
Bind local services to 127.0.0.1, validate Host headers, embed PNA headers, add CSRF tokens, and require permissions even on localhost.
Does this affect mobile browsers on Android or iOS?
The reported scope covers desktop browsers. Mobile behavior was not part of the disclosure, so treat it as unverified until the vendors say otherwise.