CVE-2026-42249, a path traversal in Ollama for Windows' updater, now has a Metasploit persistence module. No fix is confirmed; turn off auto-update.
Rapid7's 9 October 2026 Metasploit wrap-up adds exploit/windows/persistence/ollama_auto_update, a ready-made module for CVE-2026-42249, a path traversal in the update mechanism of Ollama for Windows. Anyone running the local LLM runtime on a Windows laptop or workstation is in scope, and the module turns a disclosed weakness into a point-and-click persistence step for an attacker who already has a session on the machine.
What the flaw is
CVE-2026-42249 was published on 29 April 2026 by CERT Polska, following research by Bartłomiej Dmitruk of striga.ai. The Windows updater builds local file paths from values in HTTP response headers and passes them to filepath.Join without validation. Traversal sequences (../) therefore resolve outside the update staging directory, and an executable can be written anywhere the current user can write, including the Windows Startup folder. NVD tags it CWE-22 and CWE-494. The CERT.PL-assigned CVSS 4.0 score is 7.7 (High, adjacent vector, high attack complexity). Some aggregators show 9.8 under CVSS 3.1; we did not find that score on a primary page.
It is meant to be chained with CVE-2026-42248, where the Windows update verification routine always reports success, so no signature check happens before a staged installer runs. Auto-update is enabled by default, and the combination yields silent, persistent code execution.
The module needs an existing session: it is a way to persist, not a way in.
Who can actually exploit it
The attacker has to control an update server the Ollama client will contact, for example by overriding OLLAMA_UPDATE_URL to a plain-HTTP server. That is why the CVSS vector is adjacent and the complexity high.
What the Metasploit module does
Per the merged pull request (#21423, 29 September 2026), the module needs an existing session on the target. It starts a fake update server, sets the update URL in the user's environment with setx, adds a hosts-file entry pointing ollama.com at the attacker, and serves a payload whose path traverses into the Startup folder. The payload runs at the next login. It also writes a cleanup resource file. Editing the hosts file normally needs elevated rights, which the PR does not spell out. Authors are Dmitruk and h00die.
The practical point: this is not initial access. It is a quiet way to survive reboots on a machine an attacker already reached, using a process users trust and rarely inspect.
Which versions are affected
Sources disagree, and defenders should treat the wider range as the safe assumption.
- CERT Polska and NVD: 0.12.10 through 0.17.5, the range actually tested.
- Dmitruk, as reported by The Hacker News: through 0.22.0.
- The Metasploit PR: through 0.22.1, with 0.23.0 reported patched based on the author's own testing.
The GitHub advisory lists patched versions as unknown, and the v0.23.0 release notes mention no security fix. NVD's 0.17.5 is the top of the tested range, not a fix version. Verify before telling anyone they are safe.
What defenders should do
- Inventory Windows hosts running Ollama and check versions; treat anything before 0.23.0 as exposed until Ollama confirms a fix.
- Disable automatic updates and update manually from a trusted source.
- Remove any Ollama shortcut or unknown executable from the Startup folder (
shell:startup) for each user. - Look for a user-level
OLLAMA_UPDATE_URLenvironment variable and for hosts-file entries redirectingollama.com. - Block outbound plain-HTTP update traffic and watch for the hosts file being modified.