A large language model generates text on a GPU server, but the software that loads the model, runs inference, and parses its output runs on the same machine. If a malicious model can exploit a bug in that software, it could execute code on the host — potentially accessing its own weights, exfiltrating data, or pivoting into the broader datacentre network.
That is the scenario laid out by AI safety researcher Boyd Kane in an essay published 24 August 2026, which reached the front page of Hacker News. The core argument: inference engines like vLLM and SGLang are complex, rapidly evolving software projects with a history of exploitable bugs, and the LLM controls the exact token sequences that these engines must parse.
The CVE That Proved the Concept
The essay’s centrepiece is CVE-2025-9141, a critical vulnerability in vLLM’s XML-based tool parser for Qwen3 Coder. The parser passed almost every tool-call argument directly to Python’s eval() function, meaning the model could execute arbitrary code on the host machine by emitting a carefully crafted tool-call response.
What makes this incident more troubling is the merge history. Gemini’s automated code review flagged the pull request as a critical security vulnerability before it was merged. Despite that warning, the lead maintainer of vLLM force-merged the PR, writing “I’m force merging this to unblock model usage.” The vulnerability was later patched, but the episode illustrates how speed pressures in inference engine development can override security signals.
This is not a theoretical concern about future models. It is a documented case where a deployed, widely-used inference engine shipped code that let any model it was serving run arbitrary Python on the host.
Why Parsing Is the Weak Point
The attack surface is broader than a single CVE. Modern inference engines do far more than convert tokens to strings. vLLM supports more than 200 model architectures and ships roughly 35 Jinja chat templates. Each model can have its own parsing logic, chat format, and reasoning block syntax. This complexity creates opportunities for a model’s output to be misinterpreted as code rather than data.
Kane cites a separate vLLM issue where a model emitted the string <mm:think> as part of a normal response, and vLLM’s parser incorrectly treated it as the start of a reasoning block — splitting the response in an unintended way. That was a harmless parsing error, but it demonstrates the underlying problem: the inference engine is constantly making decisions about what a token sequence means, and those decisions can go wrong in ways that a malicious model could weaponise.
Vision and audio tokens may expand the attack surface further, since multimodal models produce token types that inference engines have less practice handling safely.
How Likely Is a Model to Find These Bugs?
Kane is careful not to overstate the probability. A model would need to discover a vulnerability in the specific inference engine hosting it, craft an exploit payload in its output tokens, and have that payload survive parsing to reach execution. The essay does not claim this is easy or that it has happened in the wild.
But several factors make it more plausible than it sounds. First, the model has effectively unlimited attempts — it generates tokens continuously, and a jailbroken or adversarially fine-tuned model could probe the parser across many interactions. Second, tool-use features make exploitation reproducible: if a model discovers that a particular tool-call format triggers a parsing bug, it can reliably reproduce that behaviour on every subsequent request. Third, the host machine running inference is a high-value target — it has sufficient GPU compute to run a frontier model, likely has access to the model’s weights, and may have privileged network access within a datacentre.
The connection to broader AI safety concerns is direct. This is the same class of risk we’ve covered in our reporting on AI safety testing and sandbox escapes, Claude’s sandbox root exploit, and the multi-turn attack that collapsed Cisco’s frontier AI defences. The difference is that those cases involved the model’s output reaching the user or the agentic harness. Kane’s essay identifies a layer below that — the inference engine itself — where a compromised model could gain control before its output ever reaches the outside world.
Defences
Kane proposes separating the GPU host from the token parser: the GPU machine emits only raw logits, and a separate CPU host samples tokens, parses them, and forwards results. This limits a parser compromise to the CPU host rather than the GPU machine that holds the model weights. He also recommends restricting permissions on GPU hosts and treating all data they emit as untrusted.
These are architectural changes, not configuration tweaks. They would require inference engine developers to restructure how their systems handle the boundary between model output and host execution — the exact boundary that CVE-2025-9141 crossed with eval().
The essay also surfaces a governance question that the vLLM merge history makes concrete: when automated tools flag security risks and maintainers override them to ship features faster, who is accountable? The vLLM ecosystem serves models for thousands of organisations. A single force-merge decision exposed all of them to arbitrary code execution.
