Vulnerability Analysis

CVE-2026-42248 & CVE-2026-42249: How Ollama's Windows Auto-Updater Became a Silent Persistent RCE Vector

Executive Summary

Two chained vulnerabilities in Ollama's Windows auto-updater — CVE-2026-42248 (missing signature verification) and CVE-2026-42249 (path traversal RCE via HTTP response headers) — allow an attacker who can intercept Ollama's update traffic to silently write a malicious executable into the Windows Startup folder, achieving persistent code execution with zero user interaction. As of the time of writing, no official patch has shipped; Ollama maintainers did not engage during the 90-day coordinated disclosure window managed by CERT Polska. Every organization or developer running Ollama on Windows should disable auto-updates immediately until a patched release is confirmed.

1. What Is This Vulnerability?

Ollama is an increasingly popular open-source runtime for running large language models (LLMs) locally on developer workstations and enterprise endpoints. Its Windows build ships with a background auto-updater that silently downloads and installs newer Ollama versions. Researchers at Striga discovered that this updater contains two independently dangerous but devastatingly combinable flaws.

CVE-2026-42248 — Missing Signature Verification (CWE-494)

The Windows updater's code path includes a signature-verification routine — it is called, and the call appears legitimate. The problem: the function unconditionally returns success without performing any cryptographic check whatsoever. Whatever payload is downloaded from the update endpoint is immediately staged and executed, no questions asked.

// Simplified pseudocode of the broken verification routine
func verifyUpdateSignature(payload []byte) error {
    // BUG: validation logic is absent — always returns nil
    return nil
}

CVSS 4.0 Base Score: 7.7 (High)
Attack Vector: Network | Privileges Required: None | User Interaction: None

CVE-2026-42249 — Path Traversal via Unsanitized HTTP Response Header (CWE-22)

When the updater receives an HTTP response for the update package, it derives the local staging file path directly from the server-controlled ETag response header — without sanitizing it. An attacker who can modify or spoof this header can embed ../ sequences to redirect where the "update" is written on disk.

Combined with the Startup folder being a predictable, writable target:

# Malicious ETag header injected by attacker (example)
ETag: "../../AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/ollama_update.exe"

The updater dutifully writes the attacker's payload to the Windows Startup directory.

CVSS 4.0 Base Score: 7.7 (High)
Attack Vector: Network | Privileges Required: None | User Interaction: None

Attack Vector

The full attack chain is executed as follows:

  1. Intercept: Attacker positions themselves as a Man-in-the-Middle (MITM) on the target's network path to Ollama's update server (e.g., via ARP spoofing, rogue Wi-Fi, DNS poisoning, or a compromised network appliance).
  2. Craft response: Attacker serves a crafted HTTP response with a malicious ETag header containing path traversal sequences pointing to the Startup folder.
  3. Write payload: CVE-2026-42249's path traversal causes Ollama to write the attacker's executable into %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\.
  4. Bypass integrity check: CVE-2026-42248 ensures the fake payload clears "signature verification" without any actual check.
  5. Persist: On the next user login (or reboot), Windows silently executes the attacker's binary.

The entire chain requires zero clicks and zero user awareness. Ollama's updater runs silently in the background, making detection without dedicated tooling nearly impossible.

Real-World Impact

As of disclosure (April 29, 2026), no confirmed in-the-wild exploitation has been reported. However, the attack is highly accessible — a network-level MITM is not exotic, and the attack requires no credentials. Developer workstations on shared Wi-Fi, co-working spaces, or insufficiently segmented corporate networks are particularly at risk. The growing adoption of Ollama across AI/ML development teams makes the attack surface significant.

2. Who Is Affected?

Factor Detail
Software Ollama for Windows
Affected Versions 0.12.10 through 0.22.0 (current at time of disclosure)
Operating System Windows only (macOS/Linux builds use different updater logic)
Auto-Update Required Yes — Auto-download updates must be enabled (it is the default)
Network Position Required Attacker must be able to MITM the update traffic
Authentication Required None
Patch Available No confirmed patch as of May 10, 2026

Who is at highest risk:

  • AI/ML developers running Ollama on Windows laptops, particularly on shared or public networks
  • Enterprise endpoints where Ollama has been deployed with default settings
  • Docker/VM environments on Windows where Ollama's Windows binary is used as the host runner
  • Remote workers on home networks with insufficient segmentation

3. How to Detect It (Testing)

Manual Testing Steps

Step 1 — Check Ollama version and auto-update status

ollama --version

If the version falls between 0.12.10 and 0.22.0, the system is potentially vulnerable.

Step 2 — Check whether auto-update is enabled Navigate to Ollama's system tray icon → Settings → look for "Auto-download updates". If this toggle is ON, the vulnerability is actively exploitable.

Step 3 — Check Startup folder for unexpected entries

Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"

Any unexpected .exe files here — especially those recently modified — should be treated as suspicious. Cross-reference with known-good Ollama files.

Step 4 — Monitor for unexpected network traffic to update endpoints Using Wireshark or a network monitoring tool, watch for HTTP (non-HTTPS) connections from the ollama.exe process. Any update traffic that is not TLS-encrypted is trivially interceptable.

# PowerShell: find network connections from Ollama process
Get-NetTCPConnection | Where-Object { 
    (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Name -eq "ollama" 
} | Select-Object LocalAddress, RemoteAddress, State

Automated Scanning

  • Tool: Trivy or Grype

  • Command:

    trivy fs --severity HIGH,CRITICAL C:\path\to\ollama\install\

  • Expected output: Flags CVE-2026-42248 and CVE-2026-42249 in Ollama binary metadata once signature databases are updated.

  • Tool: OSQuery

  • Query:

    SELECT name, path, last_change 
FROM startup_items 
WHERE type = 'startup_folder' 
AND path NOT LIKE '%OllamaSetup%';

    Flag any startup entries added after Ollama installation that don't match the expected installer name.

Code Review Checklist

For teams maintaining forks or internal builds of Ollama:

  • Verify that the signature verification routine for the Windows updater performs actual cryptographic validation (e.g., Authenticode check via WinVerifyTrust)
  • Verify that all file paths derived from HTTP response headers (including ETag, Content-Disposition, Location) are sanitized and resolved to a canonical path before write operations
  • Confirm that resolved write paths are validated against an allowlist of expected staging directories (e.g., %TEMP%\ollama-update\ only)
  • Confirm that update downloads use TLS with certificate pinning or HSTS enforcement

4. How to Fix It (Mitigation)

Immediate Workaround (Until Patch Ships)

Since no official patch is available, the primary mitigation is to disable Ollama's automatic update feature:

  1. Via the UI: Click the Ollama icon in the system tray → Settings → toggle "Auto-download updates" to OFF.

  2. Via config file (for enterprise/scripted deployment): Locate %APPDATA%\Ollama\config.json and set:

    {
  "autoUpdate": false
}

  3. Block update endpoint via firewall (defense-in-depth):

    # Block outbound connections from ollama.exe to update host
New-NetFirewallRule -DisplayName "Block Ollama Auto-Update" `
  -Direction Outbound `
  -Program "C:\Program Files\Ollama\ollama.exe" `
  -Action Block `
  -RemoteAddress "0.0.0.0/0"

    Note: This blocks ALL outbound Ollama traffic. Scope to the specific update endpoint if known.

  4. Clean the Startup folder — remove any unexpected executables from the Startup directory as a precaution:

    Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" | 
  Where-Object { $_.Name -notmatch "^(Ollama|Your-Known-App)" } |
  Remove-Item -WhatIf  # Remove -WhatIf to actually delete after manual review

Step-by-Step Remediation (When Patch Available)

  1. Confirm the patched Ollama version is available via official release notes at https://github.com/ollama/ollama/releases
  2. Download the patched installer directly from the official GitHub releases page — not via the auto-updater
  3. Verify the installer's Authenticode signature before executing: 
    Get-AuthenticodeSignature ".\OllamaSetup.exe" | Select-Object Status, SignerCertificate
    Confirm Status: Valid and that the signer matches Ollama's known certificate
  4. Uninstall the current version via Add or Remove Programs before installing the patched build
  5. Re-enable auto-updates only after verifying the patch changelog explicitly addresses CVE-2026-42248 and CVE-2026-42249

Configuration Hardening

Even with a patched version, the following hardening steps reduce residual risk:

  • Run Ollama without elevated privileges — ensure the process runs as a standard user, not SYSTEM or Administrator
  • Use a dedicated service account with restricted write permissions that explicitly denies writes to Startup paths
  • Deploy Ollama behind a local proxy that enforces TLS inspection and update-endpoint allowlisting at the network layer
  • Enable Windows Defender Application Control (WDAC) or AppLocker to block unsigned executables in the Startup folder

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: After disabling auto-update, confirm that no new files appear in the Startup folder after simulating a network event to the update endpoint
  • Scenario B: (Post-patch) Run a MITM proxy serving a malicious ETag header and confirm the updater rejects the payload with an error rather than writing to disk
  • Scenario C: Confirm that Ollama's core LLM inference functionality operates normally with auto-update disabled (model loading, API endpoints, CLI commands)

Security Test Cases

Test Case 1: Verify path traversal is remediated (CVE-2026-42249)

  • Precondition: Install patched Ollama build; set up a local HTTP interception proxy (e.g., mitmproxy)
  • Steps:
    1. Route Ollama update traffic through the proxy
    2. Inject a response with ETag: "../../AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/test_payload.exe"
    3. Observe where (if anywhere) the file is written
  • Expected Result: File write is rejected or constrained to the allowed staging directory; no file appears in the Startup folder

Test Case 2: Verify signature verification is enforced (CVE-2026-42248)

  • Precondition: Install patched Ollama build
  • Steps:
    1. Serve an unsigned test executable via a MITM proxy as the "update payload"
    2. Trigger an update check
  • Expected Result: Ollama logs an error, rejects the payload, and does not execute the unsigned binary

Test Case 3: Confirm Startup folder integrity

  • Precondition: Baseline snapshot of %APPDATA%\...\Startup before test
  • Steps: Re-run test cases 1 and 2
  • Expected Result: Startup folder contents are identical to the baseline snapshot

Automated Tests

# Pseudocode: verify no unexpected startup items post-attack simulation
import os, glob, hashlib

startup_dir = os.path.expandvars(
    r"%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"
)
baseline_hashes = {"OllamaSetup.exe": "known_sha256_here"}

for f in glob.glob(os.path.join(startup_dir, "*.exe")):
    name = os.path.basename(f)
    with open(f, "rb") as fh:
        digest = hashlib.sha256(fh.read()).hexdigest()
    assert name in baseline_hashes, f"UNEXPECTED FILE IN STARTUP: {name}"
    assert baseline_hashes[name] == digest, f"HASH MISMATCH FOR: {name}"

print("Startup folder integrity check PASSED")

6. Prevention & Hardening

Best Practices

  • Treat auto-updaters as an attack surface: Any background update mechanism that fetches and executes code is a high-value target. Audit all auto-update implementations in your software supply chain for signature validation and path sanitization.
  • Enforce TLS and certificate pinning for all update endpoints: HTTP update traffic is trivially interceptable on any network. All update fetches must use TLS 1.2+ and should validate against a pinned certificate or HPKP.
  • Apply the principle of least privilege to installer processes: Update agents should never have write access to persistence paths (Startup, Run keys, Scheduled Tasks) during normal update staging.
  • Implement a SBOM and patch verification workflow for AI/ML tooling: As LLM runtimes like Ollama enter enterprise environments, they must be subject to the same patch verification lifecycle as production dependencies.

Monitoring & Detection

Set up the following detections to catch active exploitation attempts:

# Wazuh / Sysmon / EDR rule pseudocode
- name: Unexpected executable in Windows Startup folder
  trigger: FileCreate
  path: "%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*.exe"
  exclude:
    - known_installers: ["OllamaSetup.exe"]
  action: alert HIGH

- name: Ollama spawning child process after update check
  trigger: ProcessCreate
  parent: "ollama.exe"
  child: NOT IN ["ollama_llm.exe", "ollama_runner.exe"]
  action: alert CRITICAL

- name: HTTP (non-TLS) connection from ollama.exe
  trigger: NetworkConnect
  process: "ollama.exe"
  protocol: HTTP (port 80)
  action: alert HIGH

Key indicators of compromise to hunt for:

  • New .exe or .bat files in %APPDATA%\...\Startup\ with creation time close to Ollama update check schedules
  • ollama.exe spawning unusual child processes (cmd.exe, powershell.exe, mshta.exe)
  • Outbound HTTP (port 80) connections from ollama.exe — all update traffic should be HTTPS

References

Latest from the blog

See all →