Warsaw, Poland

Why I wouldn't run Ollama in an organization

Ollama is a great product for everyday use of large language models. If performance is what you care about, there are better alternatives such as vLLM, but this post is about something else.

I want to describe what happens when you find a security hole in Ollama and try to get it fixed. I went through that twice this year, for three CVEs in total. Vulnerabilities show up in any software, so they alone are not the problem. What matters is how a project handles them, and the way Ollama handles them is why I wouldn't put it on an organization's infrastructure.

What we found

At Striga we have spent the last months auditing open source software, from small community projects to code bases that are decades old. We contacted dozens of maintainers, kept our reports short and reproducible, and tried hard not to add to the flood of AI-generated noise they already deal with. Nearly all of them acknowledged the report, passed it on to whoever handles security, and came back later with a decision: a fix, or a rejection with reasons.

Ollama got three CVEs from that work:

  • CVE-2026-103663: /api/pull trusts layer digests from the registry manifest, so a crafted digest writes a file outside the model store. In the default Docker image the server runs as root and can write to /usr/lib/ollama, which it loads from on the next start. The result is unauthenticated remote code execution as root. Details in our write-up and the CERT Polska advisory.
  • CVE-2026-42248 and CVE-2026-42249: the Windows auto-updater builds file paths from HTTP response headers and never verifies what it downloads. Together they let anyone who can influence an update response drop a file into the Windows Startup folder and run code at every login. Details in our write-up and the CERT Polska advisory.

We were not the only ones to find the path traversal behind CVE-2026-103663. ylwango613 found it independently and reported it publicly in issue #17178 in July, two months before our audit, and PR #17214 proposed a fix. What we added is the escalation from a file write to code execution as root. I only came across that issue while preparing this post, after we had reported the chain and the CVE had been published, which is why the credit appears here and not in our original report.

How disclosure went

For the Windows updater:

  • 26 Jan 2026: found during the audit.
  • 27 Jan: reported by email to hello@ollama.com, the contact listed in Ollama's security policy.
  • 28 Jan: I found a core team member's address with whogit and wrote to them directly. They replied the same day and said they would look into it. Nobody wrote back after that.
  • 3 Mar: with no response, I handed the case to CERT Polska.
  • March: CERT Polska wrote to hello@ollama.com from its own address. No reaction.
  • 3 Apr: CERT Polska opened a public issue, #15262, asking how to report vulnerabilities to Ollama so that it actually works.
  • 23 Apr: CERT Polska announced it would publish on 29 April if nobody answered.
  • 29 Apr: the CVEs were published. There was no fix; the then-current release, 0.22.0, was still vulnerable. Nobody from Ollama ever replied to the issue. CERT Polska closed it themselves.
  • 11 May: PR #16100, "app: harden update flows", was merged. It adds a filename check and Windows signature verification, which fixes both CVEs. It shipped the next day in 0.23.3, where the release notes list it under that same title. There was no advisory, and the release mentioned neither the CVEs nor who reported them.

From report to publication it took three months, and the only reply came on the second day.

With /api/pull it went the same way. I reported it on 23 September and got no reply. Five days later, on 28 September, the fix shipped inside PR #18625, titled "mlx: bound pull stall retries and let the watchdog interrupt them". The commit adds digest validation to every download, but neither its message nor the pull request mentions a security problem. The 0.35.0 release notes don't mention it either. Issue #17178 and PR #17214 are still open, so anyone reading the tracker would think the bug is unfixed. CERT Polska published the CVE on 8 October.

It isn't just us

Ollama's security policy says the team "takes security seriously" and asks researchers to use GitHub security advisories. The project has published zero of them. For comparison, at the time of writing vLLM has published at least 100 and llama.cpp 15.

Other researchers describe the same thing. In issue #14666 a researcher writes that their report was quietly patched in PR #13164, and asks the maintainers to confirm it so a CVE can be assigned. The issue has been open since March without a single reply.

The problem with silent fixes

Ollama does fix these bugs eventually (sometimes only after they become public), but it doesn't tell anyone when it does.

  • Vulnerability scanners and SBOM tools work from CVEs and advisories. When a fix ships without either, the vulnerable versions look clean.
  • Release notes don't help either. If the fix for an unauthenticated root RCE ships under a title about download retries, nobody reading the changelog knows they should upgrade.
  • Linux distributions and people maintaining internal images can only backport fixes they know about.
  • If researchers can't reach the maintainers, the next one may not report at all.

If you are choosing a runtime for a team, vLLM and the llama.cpp server have their own problems, but they publish advisories and answer reports, which for me settles it.

I'd be glad to be proven wrong. If Ollama starts answering reports and publishing advisories for what it fixes, I'll update this post.