Cybersecurity researchers have revealed that Ollama has significant security vulnerabilities. Successful exploitation of this vulnerability could allow a remote, unauthenticated attacker to leak entire process memory.
This out-of-bounds read flaw can impact over 300,000 servers worldwide and is tracked as CVE-2026-7482 (CVSS score: 9.1). Codenamed Bleeding Llama by Cyera.
Ollama is a popular open source framework that allows you to run large-scale language models (LLMs) locally instead of on the cloud. On GitHub, the project has over 171,000 stars and has been forked over 16,100 times.
“Ollama before 0.17.1 has a heap out-of-bounds read vulnerability in the GGUF model loader,” according to the flaw description on CVE.org. “The /api/create endpoint accepts attacker-supplied GGUF files where the declared tensor offset and size exceed the actual length of the file. fs/ggml/gguf.go and server/quantization.go (WriteTo()) During quantization, the server reads beyond its allocated heap buffer.
GGUF (GPT-Generated Unified Format) is a file format used to store large language models so that they can be easily loaded and run locally.
The core of the issue stems from Ollama’s use of an unsafe package when creating a model from a GGUF file, specifically within a function named “WriteTo(),” which allows him to perform operations that bypass the programming language’s memory safety guarantees.
In a hypothetical attack scenario, a malicious attacker could send a specially crafted GGUF file with the tensor shape set to a very large number to the exposed Ollama server, triggering an out-of-bounds heap read during model creation using the /api/create endpoint. Successful exploitation of the vulnerability could result in the disclosure of sensitive data from Ollama process memory.
This may include environment variables, API keys, system prompts, and concurrent user conversation data. This data can be leaked by uploading the generated model artifacts to an attacker-controlled registry via the /api/push endpoint.
The chain of exploitation unfolds in three steps.
Upload a crafted GGUF file containing an inflated tensor shape to a network-accessible Ollama server using an HTTP POST request. The /api/create endpoint is used to activate model creation, resulting in an out-of-bounds read vulnerability. Extract data from heap memory to an external server using the /api/push endpoint.
“Through AI inference, an attacker can learn basically everything about an organization: API keys, proprietary code, customer contracts, etc.,” said Cyera security researcher Dor Attias.
“On top of that, engineers often connect Ollama to tools like Claude Code. In such cases, the impact is even greater. The output of all tools flows to the Ollama server, is stored on the heap, and could end up in the hands of an attacker.”
We recommend that users apply the latest fixes, restrict network access, audit running instances for exposure to the Internet, and isolate and protect instances behind firewalls. Since the REST API does not provide authentication out of the box, it is also recommended to deploy an authentication proxy or API gateway in front of every Ollama instance.
Two unpatched flaws in Ollama lead to persistent code execution
The development comes as Striga researchers detailed two vulnerabilities in Ollama’s Windows update mechanism that could cascade to persistent code execution. This flaw was not fixed after publication on January 27, 2026, and was published after the 90-day publication period.
According to Striga co-founder Bartłomiej “Bartek” Dmitruk, the Windows desktop client auto-starts upon login from the Windows startup folder and listens on 127.0.0.[.]1:11434 and periodically polls for updates in the background via the /api/update endpoint and executes any pending updates on the next app startup.
The identified vulnerabilities are related to path traversal and missing signature checks, which, when combined with the at-login routine, could allow an attacker with the ability to influence update responses to execute arbitrary code on every login. Defects are listed below –
CVE-2026-42248 (CVSS score: 7.7) – Signature validation vulnerability that does not validate update binaries before installation, unlike the macOS version. CVE-2026-42249 (CVSS score: 7.7) – A path traversal vulnerability due to the fact that Windows Updater creates the local path for the installer staging directory directly from the HTTP response headers without sanitizing it.
To exploit this flaw, an attacker would need to control an update server that is accessible to the victim’s Ollama client. This situation can lead to a scenario where an arbitrary executable file is provided as part of the update process and written to the Windows Startup folder without any signature checking issues.
To gain control over update responses, you can override OLLAMA_UPDATE_URL to point the client to the local server over plain HTTP. The attack chain also assumes that AutoUpdateEnabled is on, which is the default setting.
Additionally, missing integrity checks could allow code to execute automatically without exploiting the path traversal vulnerability. In this case, the installer will be dropped into the expected staging directory. The next time it boots from the startup folder, the update process is called without revalidating the signature and the attacker’s code is executed instead.
That being said, remote code execution is not persistent as the next legitimate update will overwrite the staged file. Adding path traversal to this allows a malicious attacker to redirect the executable to write outside of its normal path, allowing persistent code execution.
According to CERT Polska, which took over the coordinated disclosure process, Ollama for Windows versions 0.12.10 to 0.17.5 are vulnerable to two flaws. In the meantime, we recommend that you turn off automatic updates, remove existing Ollama shortcuts from your startup folder (“%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup”), and disable the silent execution pathway at login.
“Ollama for Windows installations running versions 0.12.10 to 0.22.0 are vulnerable,” Dmitruk said. “Path traversal causes an executable of the attacker’s choice to be written to the Windows startup folder. The executable remains there because there is no signature verification. Windows does no post-write cleanup to remove unsigned files on a running updater. At the next login, Windows runs what is left behind.”
“This chain generates persistent, silent code execution at the privilege level of the user running Ollama. Realistic payloads include a reverse shell, an information thief to steal browser secrets or SSH keys, or a dropper that pivots to additional persistence mechanisms, anything that runs as the current user. Removing the dropped binary from the startup folder ends persistence, but the underlying flaw remains.”
Source link
