Ollama Out of Bounds Read Vulnerability Allows a Remote Process Memory Leak

Cybersecurity researchers have disclosed a critical security vulnerability in Ollama that, if successfully exploited, could allow a remote, unauthorized attacker to leak its entire process memory.

The out-of-bounds read error, which may have affected more than 300,000 servers worldwide, is being tracked as CVE-2026-7482 (CVSS score: 9.1). Named in code Bleed Llama by Cyera.

Ollama is a popular open source framework that allows large-scale linguistic models (LLMs) to be run on-premises instead of in the cloud. On GitHub, the project has over 171,000 stars and has been forked over 16,100 times.

“Ollama before 0.17.1 contains a batch read vulnerability in the GGUF model loader,” according to the bug description on CVE.org. “The /api/create endpoint accepts an attacker-supplied GGUF file where the tensor is exceeded and the size exceeds the actual length of the file; during quantization in fs/ggml/gguf.go and server/quantization.go (WriteTo()), the server reads more than the allocated buffer.”

GGUF, short for GPT-Generated Unified Format, is a file format used to store large language models so they can be easily loaded and used locally.

The problem, at its core, stems from Ollama’s use of an unsafe package when creating a model from a GGUF file, specifically in the function called “WriteTo(),” thus making it possible to perform operations that bypass the memory safety guarantees of the programming language.

In a hypothetical attack scenario, a bad actor can send a specially crafted GGUF file to the exposed Ollama server with the tensor state set to a very large number to trigger an out-of-bounds stack read during model creation using the /api/create endpoint. Successful exploitation of the vulnerability could leak sensitive data from the memory of the Ollama process.

This may include environment variables, API keys, system information, and concurrent user chat data. This data can be refined by uploading the resulting model artifact via the /api/push endpoint to an attacker-controlled registry.

The chain of exploitation occurs in three steps –

• Upload the designed GGUF file with the ascending tensor shape to the network accessible Ollama server using an HTTP POST request.
• Use the /api/create endpoint to activate the model, eliminating the risk of out-of-bounds reading.
• Use the /api/push endpoint to push data from heap memory to an external server.

“An attacker can learn anything about an organization through your AI understanding – API keys, proprietary code, customer contracts, and much more,” said Cyera security researcher Dor Attias.

“In addition, developers often connect Ollama to tools like Claude Code. In those cases, the impact is even higher — all the results of the tools flow to the Ollama server, stored in the heap, and potentially end up in the hands of an attacker.”

Users are advised to use the latest fixes, limit network access, check for active internet exposure conditions, and isolate and protect themselves behind a firewall. It is also recommended to use an authentication proxy or API gateway in front of all Ollama instances, as the REST API does not provide authentication out of the box.

Two Unpublished Errors in Ollama Lead to Persistent Code Execution

The development comes as researchers at Striga described two vulnerabilities in Ollama’s Windows update machine that could be tied to executing code in progress. The errors remained unposted following the January 27, 2026 disclosure, and were published after the 90-day disclosure period expired.

According to Bartłomiej “Bartek” Dmitruk, the founder of Striga, the Windows desktop client starts automatically when entering the Windows Startup folder, listening on 127.0.0[.]1:11434, and periodically polls for updates in the background via the /api/update endpoint to trigger any pending updates on the next application launch.

The identified vulnerability is related to the cross-path and missing signature check, when combined with the login system, which could allow an attacker with the ability to influence the update responses to use arbitrary code for every login. Errors are listed below –

• CVE-2026-42248 (CVSS score: 7.7) – A missing signature verification vulnerability that does not verify the update binary before installation, unlike its macOS version.
• CVE-2026-42249 (CVSS score: 7.7) – A cross-path vulnerability that stems from the fact that the Windows updater creates a local path to the installer directory directly from the HTTP response headers without sanitizing it.

In order to exploit, the attacker needs to control the update server accessible by the victim’s Ollama client. In such a case, it may lead to a situation where arbitrary executables are provided as part of the update process and written to the Windows Startup folder without raising any signature verification issues.

To be able to control the update response, one method involves overriding OLLAMA_UPDATE_URL to point the client to the local server in plain HTTP. The attack chain also assumes that AutoUpdateEnabled is enabled, which is the default setting.

In addition, missing integrity checks can lead to code execution on its own without the need to exploit path-crossing vulnerabilities. In this case, the installer is released in the expected staging directory. During the next launch in the Startup folder, the update process is invoked without re-verifying the signature, causing the attacker’s code to be executed instead.

That being said, remote code execution does not continue, as the next official update closes the staged file. By adding a shortcut to compilation, a bad actor can redirect the executable to be written outside of the normal path and gain access to persistent code.

According to CERT Polska, which took over the integrated disclosure process, Ollama for Windows versions 0.12.10 to 0.17.5 is vulnerable to these two flaws. In the meantime, users are recommended to turn off automatic updates and remove any existing Ollama shortcut from the Startup folder (“%APPDATA%MicrosoftWindowsStart MenuProgramsStartup”) to disable the silent login exit method.

“Any Ollama Windows installation running version 0.12.10 to 0.22.0 is vulnerable,” Dmitruk said. “The shortcut writes executables selected by the attacker to the Windows Startup folder. Missing signature verification keeps them there: cleaning up after writing that might remove unsigned files from the active updater is not opening Windows. At the next login, Windows uses whatever is left behind.”

“The thread generates persistent, silent code execution at the privilege level of the user running Ollama. The actual payload includes reverse shells, hacking browser secrets and SSH keys, or droppers that rush into additional persistence methods. Anything that works as the current user. Extracting a dropdown folder ends in two ways, but a dropdown folder ends up binary.”