0.0.0.0 Day: Exploiting Localhost APIs From The Browser

0.0.0.0 Day: Exploiting Localhost APIs From The Browser

Speaker: Gal Elbaz

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~7 minutes

TL;DR

The IP address 0.0.0.0 is an 18-year-old bug hiding in plain sight — a single address that bypasses every browser-based private network protection ever built. Gal Elbaz, co-founder and CTO of Oligo Security, reveals how this quirk enabled a real, year-long attack campaign against AI infrastructure and how a single HTTP request from a malicious website can compromise any application running on a developer's local machine.

Introduction

eBay once port-scanned every visitor's local machine to fingerprint them. That revelation caused an uproar — but the underlying technique it exploited has never been fully closed. Nineteen years of browser security standards, private network access proposals, and cross-origin policies later, one special IP address still makes it possible to do from any website exactly what eBay was doing: reach into a visitor's local machine and talk to whatever is listening.

That address is 0.0.0.0.

Gal Elbaz, co-founder and CTO of Oligo Security, traced this problem from its roots in a 2006 Mozilla Firefox bug report all the way through a real-world attack campaign that compromised thousands of AI compute clusters in 2024 — the first documented attack in history targeting AI workloads at scale.

The History: 19 Years of Incomplete Fixes

▶ Watch: Client port scanning and the origins of PNA (2:30)

Client-side port scanning from the browser is not theoretical. When a website makes a fetch request to a local IP, the browser's response behavior — connection refused versus an error code — reveals whether a port is open. eBay used this to fingerprint visitors. A 2006 Mozilla bug report documented a variant: malicious websites were using DNS rebinding to redirect a browser's requests to home and office routers, compromising them. That attack campaign hit over 300,000 home and office routers.

Mozilla's initial response was to compile a list of "private" addresses that browsers would refuse to connect to — 127.0.0.1, RFC 1918 ranges, and others. The 0.0.0.0 address was noticed as missing and added to the list. But it remained an open enhancement request, not a shipped fix. That enhancement request has been open, without resolution, for 18 years.

Google's Chrome team independently started the Private Network Access (PNA) specification roughly eight years ago, motivated partly by CSRF attacks and partly by the same router-targeting campaigns Mozilla had documented. PNA's intent was to require preflight checks before any web page could make requests to the private network or localhost. Chrome began rolling out PNA protections — and promptly broke large portions of the web, forcing repeated rollbacks. 0.0.0.0, again, was explicitly left out of the PNA block list because real-world traffic to it appeared common enough that blocking it caused site breakage.

Why 0.0.0.0 Is Different

▶ Watch: What 0.0.0.0 actually does (14:00)

The RFC defines 0.0.0.0 as "this host on this network" — used legitimately only during the DHCP discovery handshake before an endpoint has been assigned an IP address. It is explicitly marked as an address that should never be used as a destination address. Nevertheless, when you send a packet to 0.0.0.0 on a host, the operating system redirects it to all active network interfaces on that machine.

The practical consequence: every private network protection PNA implemented was built around blocking specific ranges — 127.0.0.1, RFC 1918 space, link-local addresses. A request to 0.0.0.0 does not match any of those ranges. It is, by definition, not a private address. Yet it reaches every service bound to any interface on the target machine, including every service that localhost or 127.0.0.1 would have reached. Nineteen years of protection, bypassed by changing one field in the destination.

Google monitored how many websites were actively using 0.0.0.0 as a destination. At the time PNA work began, it was approximately 0.002% of websites. By the time Elbaz and his team disclosed the issue, that number had grown more than tenfold — and Google's internal analysis concluded that the majority of those sites appeared to be malicious.

Shadow Ray: The First AI Infrastructure Attack Campaign

▶ Watch: The Shadow Ray campaign (20:00)

The 0.0.0.0 technique became the attack delivery mechanism for what Oligo Security named the Shadow Ray campaign — the first documented real-world attack on AI production infrastructure, running undetected for nearly a year.

Ray is an open-source orchestration framework from Anyscale, used to coordinate distributed AI workloads. GPT-3.5 was trained on Ray. The framework is used by some of the largest AI operations in the world. Its default configuration binds to 0.0.0.0:8265, accepting connections from all interfaces. Oligo reported five vulnerabilities to the Ray maintainers; the maintainers disputed them, arguing that remote job execution is intended behavior and users should run Ray inside a controlled network.

The result was thousands of exposed Ray clusters on the public internet. Elbaz's team extracted the command history that Ray logs for every executed job — giving a full forensic view of attacker activity. The findings were striking:

• 62 OpenAI API tokens were found and disclosed (zero bounty was paid, despite OpenAI's stated bug bounty program).
• Hugging Face tokens for accounts that had been compromised.
• Slack tokens with access to private organizational communications.
• Stripe credentials — the ability to move actual money.
• AWS keys enabling lateral movement across cloud infrastructure.
• At least six or seven separate crypto mining operations were running simultaneously on individual machines, with the most successful attacker apparently ranked fourth globally in a crypto mining pool after having scripted itself to hunt and kill competing miners in memory.

Every piece of this attack was accessible to anyone on the public internet with a single packet.

Exploiting Localhost Through the Browser

▶ Watch: Live attack demonstration on Ray (30:00)

Elbaz's team demonstrated that the 0.0.0.0 technique allows a browser-based attack against any application running locally — not just Ray. The attack chain requires only that a victim visit a malicious website (or any website with injected advertising content). The JavaScript on that page makes a cross-origin HTTP POST request to 0.0.0.0:8265 — Ray's default port. The browser's CORS error response indicates the request was blocked from the JavaScript layer, but the packet still reached the server. Status 200 OK was returned. A second request in the chain then achieves full remote code execution.

The team's open-sourced proof-of-concept (available on their GitHub) demonstrates port scanning via WebAssembly. The attack applies to:

• Kubernetes and IDE port forwarding — commonly used by developers working locally.
• Operating system services such as AirPlay or CUPS.
• Internal network access including VPN clients and local DNS rebinding targets.

After Defcon, where Elbaz's team first presented the research publicly, the number of malicious websites using 0.0.0.0 as a destination jumped by approximately 100,000.

Browser Responses and the Path to a Fix

The disclosure reached all major browser vendors. The results were mixed:

• Microsoft Edge / Windows: Microsoft blocks 0.0.0.0 at the OS level, so the attack does not work on Windows at all, regardless of browser.
• Safari / WebKit: Apple added an if-statement to every outbound HTTP packet checking whether the destination address consists entirely of zeros, blocking it at the engine level. Elbaz calls this "an amazing job" — though he notes it adds overhead to every HTTP request globally.
• Chrome / Chromium: The Chrome team acknowledged the issue, began working on PNA fixes, and issued a bug bounty. However, the fix was again rolled back after it broke websites. The issue remains unresolved in Chromium as of the talk.
• Firefox: Mozilla continues to wait for PNA to reach full specification status before making changes, citing the instability of implementing fixes ahead of a finalized standard.

The longer-term fix gaining consensus involves pushing the block down to the fetch specification level — the HTTP standard that all browsers must implement. By blocking 0.0.0.0 as a destination at the fetch layer, all compliant browsers would inherit the protection simultaneously, eliminating the vendor-by-vendor patchwork. That work is in progress.

Notable Quotes

"By design, the thing that we were thinking we were blocking for the past 19 years are actually not blocked — and are all enabled through this one simple address. All you need to do is change the destination to 0.0.0.0 and all those attacks are revived."

"We are talking about a campaign that started for more than a year and went undetected for almost a year. This is the only existing example of a real attack on AI infrastructure."

"Everything I'm showing you was open to the public. Any one of you in this room could send one packet and run code and do whatever you wanted on this huge environment."

Key Takeaways

• 0.0.0.0 bypasses 19 years of browser private network protections. Every PNA rule, every localhost block, every RFC 1918 restriction is circumvented by a single address change.
• The Shadow Ray campaign proves this is not theoretical. Thousands of AI compute clusters were actively compromised, with attackers harvesting API tokens, cloud credentials, and financial access.
• Ray's design decision — binding to 0.0.0.0 by default — is the security community's problem to solve, not just the maintainer's. "Intended behavior" defenses do not hold when the consequence is arbitrary code execution by any internet visitor.
• Windows users are protected by default; macOS and Linux are not. Safari has deployed a fix; Chrome's fix was rolled back; Firefox is waiting for the standard.
• The fix is coming, but it is not here yet. The fetch-level specification change represents the most durable solution, but the timeline remains uncertain. Developer tooling that binds to 0.0.0.0 should be treated as an exposed attack surface today.