guide #119

Ollama heap leak (CVE-2026-5757) and inference-server memory safety

Editorial noteThis article reports on a fast-moving space. Versions, install counts and timelines are accurate as of the “updated” date above. We re-verify against primary sources (CVE database, project repositories, vendor announcements) before each update. Send corrections to [email protected].

Problem
Inference servers parse untrusted binary input in native code, and 2026 shipped a run of memory-safety CVEs in Ollama and NVIDIA Triton. Operators rarely know what the bug class is or what they can actually do about it.

Solution
Explains what CVE-2026-5757 and the three Triton DALI CVEs actually do, why this class of bug keeps recurring in inference servers, and the concrete steps an operator should take when the fix is the vendor's to write.

An inference server's job is to take structured binary input and turn it into tensors it can run. Model files, quantised weights, compressed archives, images and audio handed to a multimodal endpoint — all of it gets parsed, and most of it gets parsed in native code where a wrong offset is a memory-corruption bug rather than a caught exception. That is a poor combination: a wide attack surface, written in C or C++, sitting behind an HTTP endpoint that operators routinely forget to put behind auth. 2026 gave us a clean set of examples in two of the most widely deployed servers, Ollama and NVIDIA Triton.

## The Ollama heap leak: CVE-2026-5757

CVE-2026-5757 is a HIGH, CVSS 7.5 unauthenticated remote information disclosure in Ollama's model quantization engine. An attacker who can reach the server can read and exfiltrate its heap memory, which risks sensitive data exposure and gives an attacker a foothold for stealthy persistence.

Two words in that sentence carry the weight: unauthenticated and heap. Heap memory is where the process keeps whatever it is currently working on — other callers' prompts and tokens, buffers that were freed but not zeroed, and anything else the allocator handed out nearby. A read into that space is not a narrow leak of one field; it is a window onto the process's working set, sampled repeatedly by an attacker who keeps asking.

And it needs no credentials. Ollama's API ships with no authentication by default. If the port is reachable, the attacker does not have to get in first — being able to connect is the whole exploit. That is the difference between a bug that requires a compromised account and one that a background scan of the internet finds on its own.

## Triton's DALI backend: three more of the same shape

NVIDIA Triton produced three CVEs in its DALI backend, the data-loading and preprocessing pipeline that decodes and augments media before it reaches a model. All three are the parser eating attacker-controlled bytes and getting the arithmetic wrong.

  • CVE-2026-24264 (HIGH, 7.5): improper handling of highly
  • CVE-2026-24214 (HIGH, 8.0): an integer overflow in the DALI
  • CVE-2026-24213 (HIGH, 8.0): an out-of-bounds read in the DALI

Two of the three can reach code execution. These are not exotic bugs. An integer overflow when a buffer size is computed from an attacker-supplied length, an out-of-bounds read when an offset is trusted without a check — this is the standard failure mode of hand-written binary parsing, and DALI parses exactly the input that triggers it.

## Why this class keeps happening

The pattern is structural, not a run of bad luck.

Inference servers parse for performance, which means native code. The input is untrusted, highly structured, and full of the things that break parsers: length fields, offsets, nested containers, compression. Compute a size from an attacker-controlled length and you get an integer overflow, which gives you an undersized allocation, which gives you an out-of-bounds write or read a few lines later. Hand a decompressor a tiny highly compressed payload and you get amplification and a denial of service. Return a buffer you did not fully initialise and you get a heap leak. Each of the 2026 CVEs above is one of these three shapes.

These parsers are also hard to get right retroactively. Much of the code is old, borrowed from upstream media libraries, and difficult to fuzz to exhaustion. Meanwhile the endpoint sits on the network and people expose it — Ollama especially, because it is easy to run and its defaults do not push back.

The uncomfortable part: you generally cannot fix the parser. It is vendor C or C++, deep in the quantization engine or the DALI backend. What you control is everything around it — the broader posture is in the [security playbook](/guides/self-hosted-ai-security-playbook-2026), and this is the inference-layer slice of the same [landscape](/guides/self-hosted-ai-landscape-2026).

## What to do now

  • Upgrade. Move Ollama to the release that fixes CVE-2026-5757, and
  • Never expose Ollama's API to the internet. It defaults to no
  • **Treat every model file and every piece of media from an untrusted
  • If you do not need the DALI backend, do not load it. Attack

## The takeaway

For this class of bug you are dependent on the vendor's patch cadence, because the flaw lives in code you do not own and cannot safely rewrite. That dependence is exactly why continuous monitoring matters: the gap between a fix shipping and you applying it is the whole window an attacker gets, and you only close it if you know the CVE exists. Keep Ollama and Triton off the open internet, upgrade on disclosure, and watch the [free CVE tracker](/cves) — or point the [scanner](/scanner) at your host — so the next one in this pattern does not sit unpatched because nobody was looking.

Continue reading
guide
Pocket AI complete guide
Running self-hosted AI on portable hardware
guide
Edge AI hardware buyer's guide 2026
Pi 5 vs Mini PC vs Mac Mini
report
Self-hosted AI landscape 2026
Quarterly state of the ecosystem
section
Pocket AI hardware hub
All portable hosts reviewed
section
Agent tracker
Live stats on every agent
newsletter
Thursday digest
Weekly summary in your inbox