llama.cpp has merged server defenses that stop ordinary web pages from reaching sensitive local endpoints and block its URL fetchers from wandering into a home network.[2][3][5]
A separate startup guard refuses unauthenticated AI tools on a LAN-facing address.[1] This is a software-only security change: it needs no new GPU or extra memory, but anyone running `llama-server` beyond one computer should pay attention.
There is one awkward detail. The newest downloadable build HighVRAM inspected, b12318, contains the first CORS and DNS-rebinding fix but not all three follow-up patches.[4][5] The source is ahead of the binary.
That distinction matters more than the version number. People who leave llama.cpp on its default `127.0.0.1` address with tools disabled have a much smaller exposure. People who bind it to a LAN address, enable the agent or MCP features, or let vision requests fetch images by URL are the intended audience for this update.
What the patches close
The first merged change tightened how the server handles browser requests. It rejects foreign or null origins, cross-site requests without an Origin header, and DNS-rebinding attempts against a loopback server, while preserving same-origin UI access and non-browser clients.[5] A contributor tested the change with a small Qwen model and reported that cross-origin requests, text/plain requests, null origins and DNS rebinding returned HTTP 403 after the fix; the project’s security and router test suites passed 50 of 50 and 28 of 28 cases respectively.[5]
DNS rebinding sounds like a networking parlor trick, but the home-lab version is simple. A hostile website can arrange for its own hostname to resolve to a local address, then try to make the browser talk to software on the user’s machine. The patch validates the Host value on loopback connections instead of trusting an apparently same-origin request.[5]
Three follow-ups make the boundary less dependent on perfect configuration.
First, llama.cpp now refuses to start with server tools, MCP servers or the MCP proxy enabled on a non-loopback address when no API key is set.[1] The operator can bind to loopback, add an API key, or deliberately pass `–allow-unauthenticated-tools` on a trusted network.[1] That is a sensible failure mode because llama.cpp’s built-in tool set can include file reading, file editing and shell-command execution.[4]
Second, the CORS proxy and media downloader now reject loopback and private-network destinations by default.[2] The project says it tested ordinary private addresses, redirects to `127.0.0.1` and a DNS-rebinding host.[2] A vision request can still fetch a public image, but an image URL pointing at a NAS or another LAN service requires the new `–media-allow-private-urls` opt-in.[2]
Third, browsers can no longer connect directly to the loopback-only child processes created by llama.cpp’s multi-model router.[3] Local command-line programs and scripts remain trusted; the block uses browser request headers to distinguish that direct browser access.[3]
These pull requests do not document an active attack, and one maintainer explicitly described the non-loopback tools guard as hardening rather than a vulnerability.[1] The private-URL patch is blunter: its author wrote that direct home-computer deployments had turned the behavior into “a real problem.”[2] The evidence supports updating and tightening configuration, not declaring that every old server was compromised.
What HighVRAM verified
HighVRAM downloaded the public b12318 Apple-silicon binary and its matching source archive.[4] The command-line help confirms that `llama-server` still binds to `127.0.0.1` by default, leaves tools disabled, and warns against enabling tools or the agent in untrusted environments.[4] Those defaults are safer than a LAN-facing agent.
The same b12318 help does not contain `–allow-unauthenticated-tools` or `–media-allow-private-urls`. Its source archive contains the initial browser-origin and DNS-rebinding tests, but not the later startup guard or private-address resolver added by the follow-up merges. In the source at merge commit `8954f194837d2ec4d5f67f20c81b84abe63883ba`, both options and the new checks are present.[1][2]
This was a source and binary inspection, not a penetration test. HighVRAM did not expose a server to the internet.
The practical consequence is that downloading b12318 is not enough to obtain every defense described here. Wait for a build whose help lists both new options, or build a later source revision if you already maintain llama.cpp from source. A merged patch is available code; it is not automatically an installed fix.
Who should change something now
If `llama-server` runs only on the same machine and you have not changed the default host, keep it that way unless another device genuinely needs access. No GPU family, model format or quantization is affected. An 8GB gaming PC and a 512GB workstation get the same protection because the change lives in the HTTP server.
If phones, laptops or other home-lab machines connect over the LAN, use an API key and a firewall rule that limits access to the devices or subnet you expect. Do not use the new unauthenticated-tools override merely to make an error disappear. It restores the risky configuration the guard is trying to stop.[1]
If you feed a local vision model images from a NAS, the safer default will break those HTTP URLs once the full patch set reaches a build.[2] Prefer a deliberately exposed read-only media endpoint. Use `–media-allow-private-urls` only when the server and every client allowed to submit image URLs are trusted, because the switch reopens access to private addresses.
Reverse-proxy users should also test their browser path after updating. The initial hardening requires the public site origin to appear in `–cors-origins` when a proxy sits in front of the agent UI; the contributor called out that compatibility change during review.[5]
For everyone else, the decision is easy: do not rush to b12318 for the follow-up protections. Check the next build’s help first. The useful release is the one that fails closed on a careless LAN-facing agent, not merely the one whose source branch already knows how.