A local server on 127.0.0.1 is not private from the browser next to it

On 8 November a post in r/LocalLLM argued that any website open in another tab can send requests to a local inference server bound to 127.0.0.1, and that the binding accomplishes nothing, because the browser sits on the same machine. The thread carried roughly 455 points and 136 comments. The author, who says he tested rather than read about it, describes it as plain CSRF and DNS rebinding, 20-year-old web stuff. His uncomfortable sentence for anyone running a model on a laptop: "It only binds 127.0.0.1" doesn't save you.

What he actually tested

He writes that quite a few of the popular servers answer out of the box. That is one person's self-report, with no list of versions, so it is a lead rather than a measurement. What the post documents is his own setup. He patched the engine he runs, capy-flash, to refuse cross-origin and rebinding requests on a loopback bind, and he notes that his served models already sat behind a small proxy, vramble, that blocks cross-origin POSTs, so only the raw engine port was exposed. He limits the claim himself: it only works while you are browsing with the server running.

What the documentation says, server by server

This part is checkable. The llama.cpp server README documents the configuration the post describes: --host defaults to 127.0.0.1, --cors-origins defaults to *, CORS credentials are enabled, and with a wildcard origin the server echoes back whatever Origin it receives. --api-key defaults to none. The flags do tighten for --tools, --agent or an MCP config, which fall back to localhost origins, and the server prints a startup warning when CORS is open with no key set. vLLM ships the opposite: --allowed-origins defaults to an empty list, with docs stating that cross-origin browser access is disabled by default, though --api-key is unset and misses some endpoints. LM Studio keeps CORS off unless you pass --cors, and its CLI page prints a security warning there. Ollama binds 127.0.0.1 by default and fixed this class of bug in 2024, after NCC Group demonstrated a DNS rebinding attack that read files through its API.

The agent shares the tab

The sharper point is not about a stranger's website. Anything that drives a real browser on the same machine can take the same path, and a browsing agent working on your behalf is exactly that. A local model you think of as private becomes an endpoint with a user interface. The mitigations are cheap: set an API key and --cors-origins localhost, or keep a proxy in front that refuses cross-origin POSTs, as the poster did. Chrome's Local Network Access work would put these loopback requests behind a permission prompt, but only in browsers that ship it. The server-side fixes are not defaults you inherit.