Researchers at Striga have disclosed two vulnerabilities (CVE-2026-42248, CVE-2026-42249) in Ollama’s Windows auto-updater that, when chained together, may allow an attacker to covertly plant a persistent executable that runs on every login.

CVE-2026-42248 and CVE-2026-42249

Ollama is an open-source tool for running large language models locally. It’s is used by those who don’t want their data to leave their machine and don’t want to be constrained by API costs, usage limits, or the requirement of an internet connection.

“The Windows desktop client bundles the local Ollama server, a chat UI, and a system-tray icon. It auto-starts on login and checks for updates in the background. Striga surfaced the [vulnerability] chain during an audit of the Ollama repository,” Striga co-founder Bartłomiej Dmitruk explained.

CVE-2026-42248 is straightforward: the Windows build’s auto-updater signature verification function exists, it gets called, but it does nothing, and whatever is downloaded gets executed. (The macOS Ollama build performs proper code-signing checks, the researchers found.)

CVE-2026-42249 is a path traversal flaw, and stems from the fact that Ollama’s Windows updater builds the local path for a staged installer directly from HTTP response headers without sanitizing them.

An attacker who controls the update response can supply a malicious ETag header with ../ sequences and write an arbitrary executable straight into the user’s Windows Startup folder, Dmitruk noted.

Because the signature check returns “no error”, the post-write cleanup that would normally remove an unsigned file never runs, and the payload survives indefinitely. On the next login, Windows runs whatever was dropped there, and there is no warning (since the dropped file does not carry a Mark-of-the-Web tag).

“The same dropped binary fires on every subsequent login until the file is removed,” he pointed out, and added that the missing verification without the path traversal also provides remote code execution through Ollama’s normal update flow, but no persistence.

Attack prerequisites

For successful exploitation, an attacker needs to control the update response Ollama receives.

Dmitruk identified three paths: by compromising the update infrastructure directly; redirecting the client to an attacker-controlled server via a local foothold (the OLLAMA_UPDATE_URL variable, a hosts file edit, or a rogue root certificate); or network-level interception via TLS MITM or DNS hijacking with a forged certificate.

Other attack requirements include the Auto-update option being on (it’s on by default) and Ollama “sitting” in the Startup folder (it is by default).

“For the secondary path (CVE-2026-42248 alone, without traversal), Ollama additionally needs to be launched from the Startup-folder shortcut so DoUpgradeAtStartup fires. The primary chain does not need this; Windows runs the dropped file from the user’s Startup folder regardless of Ollama,” he told Help Net Security.

Striga researchers reported the findings to Ollama’s documented security address in late January 2026, Dmitruk said, and that address never replied. A maintainer’s personal email yielded one acknowledgement, then silence, he told us. “We have not seen any public statement from the maintainers about either CVE.”

After five weeks with no engagement, CERT Polska took over coordination of disclosure, assigned the CVEs, and published a warning on April 29, confirming that Ollama for Windows versions 0.12.10 through 0.17.5 are vulnerable.

What should users do?

“CERT Polska tested 0.15.1 end-to-end with our PoC and listed that as confirmed-vulnerable, deliberately cautious about untested releases,” Dmitruk told Help Net Security.

“We extended the verification: ran static checks across every release tag for the four chain indicators – (filepath.Join(UpdateStageDir, etag, …), verifyDownload(){ return nil }, OLLAMA_UPDATE_URL override, STARTF_TITLEISLINKNAME detection) – and confirmed all four present from v0.12.10 (when the rewritten desktop-app code was merged) through v0.22.0, with no commits in that range touching the vulnerable functions.”

The latest Ollama release (v0.23.0) shipped two days ago, again with no patch, he told us.

Help Net Security has reached out to the Ollama maintainers to ask when they plan to push out fixes, but haven’t heard back from them.

Until a definitive solution is provided, Dmitruk advises users to switch off the Auto-download updates option in Ollama’s settings.

“Turning it off short-circuits the background download check (updater.go:324) before any update response is fetched, so the path traversal write never happens and nothing lands on disk. Users who want to be thorough should also remove any existing Ollama shortcut from %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup to disable the silent on-login execution route.”

Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!