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 compressed data can cause denial of service. The classic decompression-amplification failure — a small input that expands into a large amount of work or memory.
- CVE-2026-24214 (HIGH, 8.0): an integer overflow in the DALI backend that can lead to code execution, data tampering, or denial of service.
- CVE-2026-24213 (HIGH, 8.0): an out-of-bounds read in the DALI backend that can lead to code execution, data tampering, denial of service, or information disclosure.
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, and this is the inference-layer slice of the same landscape.
What to do now
- Upgrade. Move Ollama to the release that fixes CVE-2026-5757, and Triton to the one that fixes the three DALI CVEs. This is the only step that removes the bug rather than hiding it.
- Never expose Ollama's API to the internet. It defaults to no auth, so a reachable port is an open door. Bind it to localhost or a private interface. If you genuinely need remote access, put an authenticating reverse proxy with rate limits in front of it — auth to stop anonymous callers, rate limits to slow the repeated sampling a heap-leak exploit depends on.
- Treat every model file and every piece of media from an untrusted source as hostile input. A random GGUF from a forum and an image uploaded by a stranger are both attacker-controlled bytes heading into a native parser. Pin the models you trust; do not point a public media endpoint at DALI without thinking about who feeds it.
- If you do not need the DALI backend, do not load it. Attack surface you do not run cannot be exploited. Same logic for any optional backend or format handler.
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 — or point the scanner at your host — so the next one in this pattern does not sit unpatched because nobody was looking.