Ollama Bleeding Llama and Windows Auto-Update RCE: Patch, Restrict Exposure, Disable Windows Auto-Update

Cyera Research disclosed CVE-2026-7482 ("Bleeding Llama") on May 5, a CVSS 9.1 unauthenticated heap out-of-bounds read in Ollama's GGUF model loader that lets a remote, unauthenticated attacker leak arbitrary process memory (system prompts, API keys, environment variables, other users' conversation data) in three HTTP calls. Cyera estimates roughly 300,000 Ollama servers are currently internet-exposed. The fix shipped February 25 in Ollama 0.17.1, but per Echo (the third-party CNA that finally assigned the CVE on April 28), the original 0.17.1 release notes did not flag it as a security update, so many operators never realized they should upgrade. Separately, Striga and CERT Polska published CVE-2026-42248 and CVE-2026-42249 on April 29: a path traversal plus no-op-signature-verification chain in Ollama's Windows auto-updater that produces persistent silent code execution at every login. That chain has no published fix; no public release notes or advisory indicate a fix in v0.23.0 through the current v0.23.2, and Striga confirmed the vulnerable indicators through v0.22.0. The vendor acknowledged Striga's report in January and then went silent through the standard 90-day disclosure window.

Framing note: two separate vulnerability classes in the same product, disclosed in the same window, with the same vendor-responsiveness pattern (slow CVE assignment on Bleeding Llama, no response on the Windows chain). This bulletin treats them as one operator response because most affected operators are on the same Ollama install they have not been told to upgrade. The third issue, CERT/CC VU#518910 / CVE-2026-5757 (Jeremy Brown), describes the same class of OOB read-and-write in Ollama's quantization engine; whether 0.17.1's fix addresses it is not publicly clarified.

Priorities, by deployment

Triage on three axes: is the Ollama API reachable from anywhere outside the local host, is the install on Windows with auto-update enabled (the default), and is the install on a version older than 0.17.1. Many operators will have all three.

Categorization source: Bulletin's framing based on Cyera's CVSS 9.1 and exposure estimate, and Striga / CERT Polska's confirmation that the Windows updater chain is unpatched on every current release.

Am I affected?

1. What version of Ollama am I running?

ollama --version
# or, if the server is running but the CLI is on a different host:
curl -s http://<ollama-host>:11434/api/version

If the version is below 0.17.1, the host is vulnerable to Bleeding Llama. If the version is 0.17.1 or later, the Bleeding Llama heap-OOB-read is patched, but unauthenticated API access remains the design default and the Windows auto-update chain (if applicable) remains unpatched.

2. Is the API reachable beyond localhost?

Check what address Ollama is bound to:

# On the Ollama host, find the listener:
ss -tlnp | grep 11434
# Or, from another host on your network:
curl -s -o /dev/null -w "%{http_code}\n" http://<ollama-host>:11434/api/version

A 200 from a remote host means you are reachable from at least that subnet. To check public-internet exposure, consult your asset inventory or run an external scan against port 11434. Cyera explicitly recommends Shodan as an audit input. The Ollama process environment is reachable through Bleeding Llama, so anything in OLLAMA_HOST, OLLAMA_ORIGINS, and any other environment variables (including unrelated secrets shared with the shell that started the daemon) is in scope of leak.

3. (Windows only) Is auto-update enabled and is Ollama in the Startup folder?

Auto-update is on by default. Confirm in the Ollama Settings UI (system tray icon, Settings, look for "Auto-download updates"). To check the Startup folder:

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

A first-run install creates an Ollama shortcut here by default; that shortcut is what triggers the silent on-login update routine that the path-traversal chain abuses. The shortcut itself is not the vulnerability; the vulnerability is that every Ollama startup from this folder runs any installer staged by the (broken) updater. Removing the shortcut blocks the silent execution path even if the updater were tricked into staging a malicious binary in %LOCALAPPDATA%\Ollama\updates\.

4. (Windows only) Can I see whether OLLAMA_UPDATE_URL is set?

# User scope:
[Environment]::GetEnvironmentVariable("OLLAMA_UPDATE_URL", "User")
# Machine scope (requires admin):
[Environment]::GetEnvironmentVariable("OLLAMA_UPDATE_URL", "Machine")

A non-empty value is suspicious unless you set it yourself. The Striga PoC documents this variable as the cleanest demonstration path for the chain because it bypasses the need for TLS interception. If you find an unexpected override pointing at a non-Ollama domain or an HTTP (not HTTPS) URL, treat the host as potentially compromised: something with environment-write capability has run on the machine.

Response, by priority

If the Ollama API is reachable from any network beyond localhost (Highest / Higher)

1. Restrict network exposure first, patch second. Patching to 0.17.1+ closes the heap-OOB-read but does not change the fact that /api/create and /api/push are unauthenticated in the upstream distribution. An unauthenticated /api/push is its own problem (anyone can upload arbitrary models to your server and consume disk and compute), and any future bug class in Ollama's parsers becomes another Bleeding Llama on a network-reachable instance. Bind to 127.0.0.1 (set OLLAMA_HOST=127.0.0.1:11434 and restart the service), or firewall port 11434 to allow only known client subnets, or both. If remote access is operationally required, put an authentication proxy in front: Tailscale, Cloudflare Access, an OAuth2 proxy, or basic-auth on a TLS-terminating reverse proxy. The "no auth by default" posture is documented behavior, not a bug, and operators carry the responsibility to add it. Common remote-access patterns that bypass localhost binding without solving the auth gap: Docker port forwards from 0.0.0.0, Kubernetes services exposing 11434 via NodePort or LoadBalancer, ngrok / cloudflared tunnels stood up for a demo and never torn down. Audit each before declaring the API closed.
2. Upgrade to Ollama 0.23.2 or later. The Bleeding Llama patch is in 0.17.1, but if you are upgrading anyway, take the current stable. Cyera's three-call chain relies on the OOB read in WriteTo(); that path now validates tensor element counts against actual buffer sizes before quantization. After upgrade, confirm the version with ollama --version from the same shell as the running daemon (a new binary on disk does not help if the running process is still the old one; restart the service).
3. Assume environment variables, system prompts, and recent conversation data have been disclosed if your server has been internet-reachable on a pre-0.17.1 version for any meaningful window. Cyera's exploitation chain is silent (the server logs no errors and does not crash), so absence of evidence is not evidence of non-exploitation. Treat any secrets that were in the Ollama process environment as potentially compromised: rotate API keys, tokens, model-registry credentials, and any third-party service credentials used by integrations that ran through Ollama. Audit recent /api/push calls in your reverse-proxy or network logs for pushes to unexpected hostnames; the data exfil step requires pushing to an attacker-controlled registry, so any /api/push to a hostname you do not recognize is a worth-investigating signal.
4. Audit agentic-tooling integrations that route through Ollama. Cyera flags this specifically: any integration explicitly configured to route tool outputs through Ollama (custom agent harnesses, LangChain-style pipelines, IDE integrations, or anything proxying Claude Code or similar through a local Ollama endpoint) writes those outputs into the same process heap that Bleeding Llama leaks. File contents, repository data, intermediate code, and any data the agent has read pass through. If those flows ran on a pre-0.17.1 server during the disclosure window, treat the contents as potentially leaked. (Plain Claude Code installations not configured to route through Ollama are not in scope.)

If you run Ollama for Windows (Higher, in addition to the network steps above)

1. Disable auto-download updates in Ollama Settings. This is the single most important Windows-side action and is currently the vendor's only mitigation for the updater chain. Open the Ollama tray icon, Settings, and toggle off "Auto-download updates." Per Striga, this short-circuits the periodic background check before any update response is fetched, so the path-traversal write never happens regardless of what an attacker's update server returns. A non-tray-UI alternative: set the registry or per-user settings file to disable auto-update; Ollama's settings storage is at %LOCALAPPDATA%\Ollama\app.json on current builds, but the supported method is the Settings UI toggle.
2. Remove the Ollama shortcut from the Windows Startup folder. This breaks the silent on-login execution route that runs any pending installer invisibly:

   Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\Ollama.lnk" -ErrorAction SilentlyContinue

   Without the Startup-folder shortcut, Ollama no longer auto-runs on login, which means the STARTF_TITLEISLINKNAME hidden-mode detection never triggers and DoUpgradeAtStartup never runs. Start Ollama manually when you actually need it. Even if the (broken) updater were somehow tricked into staging a malicious installer, no Startup-folder shortcut means no silent execution.
3. Inspect the updater staging directory and Startup folder for unexpected executables. The chain's artifact is a file written outside the legitimate staging directory. Spot-check both:

   # Legit staging directory (look for staged installers
   # Ollama is unaware of, e.g. files Ollama did not create):
   Get-ChildItem "$env:LOCALAPPDATA\Ollama\updates\" -Recurse -ErrorAction SilentlyContinue
   
   # Startup folder (look for any .exe, not just Ollama-named):
   Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\" -Filter *.exe

   Any executable in the Startup folder that is not something you put there is a finding. The Striga PoC writes OllamaSetup.exe there, but a real attacker would pick a less obvious name. Treat unknown executables in Startup as IR-level findings, not as something to delete-and-move-on; preserve a copy and check $env:LOCALAPPDATA\Ollama\ logs for the time of the write.
4. Confirm OLLAMA_UPDATE_URL is unset (per the diagnostic above). If it is set to anything other than the Ollama default, find out who set it. A non-default value is the simplest path for the chain because it removes the need for TLS interception.
5. Watch for a vendor patch. The Windows updater chain has been disclosed publicly since April 29 with no vendor response in the 90-day window. The bulletin will update if and when Ollama ships a Windows build that fixes the no-op signature check and the path-traversal write. Until then, do not re-enable auto-update.

Architectural takeaway

Local-AI runtimes inherit the same trust assumptions desktop apps had in the early 2000s, with one important difference: they bind a high-value parser (model loaders that consume attacker-influenceable binary formats) to a network port that the documentation encourages users to expose. Ollama's defaults (no auth, 127.0.0.1 by default but OLLAMA_HOST=0.0.0.0 documented as the standard remote-access pattern) make the network-reachable configuration the path of least resistance, and the ~300,000 exposed servers Cyera counted are the predictable result. This is the same shape as the broader pattern this bulletin has been tracking through 2026: the xinference framework supply-chain compromise (April), the Lightning PyPI package compromise (April), and now Ollama. AI/ML infrastructure is being pulled into production deployments faster than its security posture matures. Operator-side compensation, network restriction, authentication proxies, egress controls, secrets hygiene, is the realistic baseline until upstream defaults catch up.

The Windows-updater finding is a separate but related pattern: software that ships its own updater inherits the full responsibility of a code-signing trust chain, and cutting corners on Windows specifically (where the macOS build does the right thing) is a recurring failure mode. The DAEMON Tools supply-chain compromise (May 5) is a different mechanism but the same outcome: the binary that runs on user machines is not the binary the vendor signed. Trust-chain failures are a 2026 theme, not a 2026 anomaly.

And the meta-pattern in this story is the disclosure experience itself. Cyera's CVE took three months and a third-party CNA (Echo) to assign because MITRE did not respond, and the original 0.17.1 release notes did not flag the fix as security-relevant. Striga's reports went to the Ollama security contact in January and were met with silence. CERT Polska had to take over coordination. CERT/CC published VU#518910 with no vendor coordination at all. The operator-visible result is that even a fix that exists may not be a fix the operator knows about, and operators with auto-update enabled on Windows are auto-updating into a runtime whose updater is the bug. Anchor your scanner coverage and your patch-tracking against authoritative CVE records (Echo / CERT Polska / CERT/CC) rather than vendor release notes for products with this disclosure pattern.