Everybody's phone is about to blow up with Pixel 9 news today so I'm going to deliberately not write about that, because by Friday there'll be forty posts about the new Pixel Watch and I don't need to be the forty-first. Instead I want to talk about a bug that's dumber, older, and honestly more interesting once you sit with it.
Last week, around DEF CON, a security outfit called Oversecured published research on something they're calling "0.0.0.0-Day." The short version: browsers have a blind spot around the address 0.0.0.0, and it's been there since roughly 2006. Eighteen years. That's older than this blog.
Here's the mechanism, as best I understand it. You know 127.0.0.1, "localhost," the address that always points back at your own machine. Browsers are (mostly) careful about letting a random website on the internet send requests to 127.0.0.1, because that's obviously how you'd poke at stuff running locally, dev servers, admin panels, whatever. But 0.0.0.0 is a weird address too, it's technically a wildcard meaning "any address on this host," and it turns out a chunk of network stacks will happily route a request to 0.0.0.0 straight to a service listening on localhost anyway. Chrome, Firefox, Safari, all of them, on macOS and Linux specifically (Windows blocks it, one of the rare times Windows networking defaults win). And the browser-side protections built to stop cross-origin shenanigans just never accounted for that address existing.
So a malicious webpage, one you clicked a link to from an email or an ad, can send a request to http://0.0.0.0:PORT and it lands on whatever's running on your machine at that port. No popup, no permission prompt, nothing.
I did the obvious thing and checked my own laptop. I had a local Ollama instance running (I've been messing around with running small models locally for a side project I'll probably never finish) sitting wide open on its default port with zero auth, because who's going to hit it, right, it's localhost. Except apparently a website I have open in another tab could, in theory. I also had an old Redis instance from some tutorial I never cleaned up. Neither had anything sensitive on them, thank god, but it's the principle of the thing. I've been building software since before this blog existed and it never once occurred to me that "it's only reachable from localhost" wasn't actually true.
The researchers found this pattern is depressingly common with local dev tooling, the stuff engineers spin up and forget about: Docker daemons, various local LLM servers, Selenium grids, internal dashboards that assume "nobody outside my machine can hit this" is a security boundary instead of a suggestion. A lot of AI tooling in particular ships with an unauthenticated local API because during development that felt like a reasonable shortcut. Turns out it wasn't.
Google, Mozilla and Apple have all said they're working on blocking requests to 0.0.0.0 from the browser side, which is the right fix, it shouldn't be on every individual dev to remember to put auth on their localhost tools. But "working on it" isn't shipped, and eighteen years of this existing quietly tells you how long these things can sit around before anyone bothers to look. I don't think there's some grand lesson here beyond: go check what's listening on your machine right now, actually go do it, lsof -i -P or whatever your OS's equivalent is, and be a little suspicious of anything with no password just because it's "local."
Also, unrelated complaint while I'm here: half the tutorials that get you into this mess in the first place tell you to bind to 0.0.0.0 instead of 127.0.0.1 specifically so you can reach the service from another device on your network, which is fine and useful, except then people leave it that way forever and forget why they did it. I've done this exact thing. More than once. Old habits, bad defaults, nobody reads the docs section about turning auth back on.
Anyway. Go check your ports.