The header-validation fix for this class of bug already shipped once. Ollama closed DNS rebinding against its API in v0.1.29 on March 14, 2024, and NCC Group published it as CVE-2024-28224 the following month, with the recommendation to validate the Host header on the server against a set of authorized values [18]. About 29 months later the same door is open, and not because anyone reverted the code [1]. The API on 11434 has no authentication and leans on two middleware layers to keep browsers out; when the bind address is not loopback, the Host check is skipped outright, and the CORS layer then reads Origin and Host as the same attacker-controlled domain and permits the call [13][14]. Where the attacker cannot serve their page on 11434 itself, rebinding covers it: their domain resolves to their server, then to 127.0.0.1, while the browser goes on treating the requests as same-origin [15]. A bind address decided which branch ran.
NemoClaw is NVIDIA's open source reference stack for running agents such as OpenClaw inside its OpenShell sandboxes, with Ollama as one supported local inference backend [5]. Its Ollama handling is not uniform. Non-WSL hosts get 127.0.0.1:11434 behind a token-gated reverse proxy on 0.0.0.0:11435, and onboarding restarts a daemon bound elsewhere back to loopback [9]. The Windows-host path is the one that sets OLLAMA_HOST=0.0.0.0:11434 so Docker Desktop containers can reach the daemon, with no authentication in front of it [11]. The question an operator has to answer is therefore not whether they run NemoClaw but which of those arrangements their install picked, and that is a question about a systemd unit and a Docker Desktop setting rather than a version string.
The project has moved on this already, in a way that shows the seam. Since v0.0.106 on August 10, the local Ollama proxy refuses to start against a backend that is not bound to loopback, exiting with a dedicated status code and telling the operator to put OLLAMA_HOST=127.0.0.1 on the Ollama systemd unit [22][23]. Fifteen days later that was still the default in the tree The Hacker News read [2]. But the guard is a property of the proxy, and the Docker Desktop on WSL path skips the proxy entirely, because the container reaches the host's loopback through host.docker.internal [10]. A check that lives in the component the exposed path does not run is not a mitigation for that path [3]. There is also an override, NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1, for anyone who wants the older behaviour back [24].
The write lands below the API surface, which is why it sticks. The agent still supplies its own system prompt, and according to the report the planted instructions survive that and carry into later conversations [20]. Nothing in the agent changed, so restarting it or tightening its prompt leaves the stored template exactly where the attacker put it [4].
