CVE-2026-42248: 
NixOS vulnerability analysis and mitigation

CVE-2026-42248 is a missing integrity verification vulnerability in Ollama for Windows that allows network-adjacent attackers to execute arbitrary code by supplying malicious update executables. The Windows implementation of Ollama's update verification routine unconditionally returns success, bypassing all digital signature and trust validation before staging or executing update payloads. Versions 0.12.10 through 0.17.5 are confirmed vulnerable; other versions may also be affected. It was disclosed on April 29, 2026, with a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 7.7 (High) (GitHub Advisory, CERT.PL).

The root cause is classified as CWE-494 (Download of Code Without Integrity Check): the Windows-specific update verification function unconditionally returns a success status without performing any cryptographic signature validation or trust chain verification on downloaded executables (GitHub Advisory). An attacker positioned on the same network segment (or capable of intercepting/redirecting update traffic) can serve a malicious executable that Ollama will stage and execute as a legitimate update payload. The silent automatic update mechanism compounds the risk, as no user interaction or awareness is required for the malicious payload to execute. A Metasploit module (ollama_update_etag_traversal.rb) has been published that implements the full exploit chain, including path traversal via manipulated ETags to deliver arbitrary payloads (Metasploit Module).

Successful exploitation allows an unauthenticated attacker to achieve remote code execution with the privileges of the Ollama application process on the victim's Windows system, resulting in high confidentiality, integrity, and availability impact. Because updates are applied silently and automatically, a malicious payload can establish persistence or deploy backdoors without any user interaction or awareness (GitHub Advisory, Striga Research). The vulnerability also enables lateral movement potential if the compromised host has access to internal network resources, and sensitive AI model data or system credentials stored on the host may be exposed (Help Net Security).

A functional Metasploit module (ollama_update_etag_traversal.rb) is publicly available that implements the complete exploit chain, including ETag-based path traversal and malicious executable delivery (Metasploit Module). As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and no threat actor attribution has been made (GitHub Advisory). The EPSS score is approximately 0.026% (8th percentile), and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability does not require authentication or user interaction, lowering the bar for exploitation significantly.

1. Reconnaissance: Identify Windows hosts running Ollama versions 0.12.10–0.17.5 on the local network using network scanning tools (e.g., Nmap) or by monitoring for Ollama's update check traffic.
2. Position for interception: Gain a network-adjacent position capable of intercepting or redirecting Ollama's update HTTP/HTTPS requests — for example, via ARP spoofing, DNS poisoning, or a rogue access point on the same network segment.
3. Set up malicious update server: Deploy a server that mimics Ollama's update endpoint and serves a malicious Windows executable as the update payload. The Metasploit module ollama_update_etag_traversal.rb automates this step, including crafting manipulated ETag headers to exploit path traversal and deliver the payload.
4. Intercept update check: When Ollama for Windows performs its automatic update check, redirect the request to the attacker-controlled server. The server responds with a crafted response indicating a new update is available, along with the malicious executable.
5. Bypass verification: Because the Windows update verification routine unconditionally returns success, no signature or integrity check is performed on the downloaded executable.
6. Achieve code execution: Ollama silently stages and executes the malicious payload with application-level privileges, enabling persistence, reverse shell establishment, data exfiltration, or further lateral movement (Metasploit Module, Striga Research).

• Network: Unexpected HTTP/HTTPS requests from Ollama processes to non-official update endpoints; DNS queries for Ollama update domains resolving to unexpected IP addresses; outbound connections from the Ollama process to unknown external hosts following an update check.
• File System: Unexpected or unsigned executables written to Ollama's installation or staging directory (e.g., %LOCALAPPDATA%\Programs\Ollama\ or temp directories); newly created executables with names resembling Ollama update files but lacking valid digital signatures.
• Process: Unusual child processes spawned by the Ollama process (e.g., cmd.exe, powershell.exe, curl.exe); new scheduled tasks or registry run keys created by the Ollama process; unexpected network connections initiated by child processes of Ollama.
• Logs: Windows Event Logs showing process creation events (Event ID 4688) with Ollama as the parent process and unexpected child executables; application logs showing update download and execution events outside of normal update schedules (Striga Research, CERT.PL).

Update Ollama for Windows to a version beyond 0.17.5 that includes a patched update verification routine with proper digital signature validation (GitHub Advisory). As an interim workaround, disable automatic updates in Ollama and manually verify the authenticity and digital signature of any update executable before installation. Implement network-level controls (e.g., firewall rules, DNS filtering) to restrict Ollama's update traffic to verified, official endpoints only. Monitor for suspicious update behaviors and unexpected executable execution as described in the IOCs section (Striga Research).

CERT Polska (CERT.PL) published a detailed advisory on the vulnerability shortly after disclosure, noting that project maintainers were notified early but did not respond with details about the vulnerable version range (CERT.PL). Help Net Security and The Hacker News covered the vulnerability as part of broader reporting on Ollama Windows security issues, highlighting the silent auto-update mechanism as a particularly dangerous attack surface (Help Net Security). Security researchers at Striga published a dedicated technical write-up on the auto-update RCE chain, and the vulnerability was dubbed "Bleeding Llama" in community discussions (Striga Research, Threat Road). Community sentiment on platforms like Mastodon and Bluesky reflected concern about the lack of vendor response and the availability of a working Metasploit module.