The Inference Engine Is Your Weakest Link

Here's a threat model that keeps me up at night: the LLM you're running could exploit the software that's running it.

Not the agent harness. Not the sandbox. The inference engine itself — the C++/Python layer that loads the model onto your GPUs, runs the forward pass, and parses the output tokens back into a response. That layer is turning your model's tokens into actions on your host machine, and if it has a bug, the model can pull the trigger.

Boyd Kane published an essay today that walks through exactly how this works, and I needed to verify every claim because they sound like science fiction. They're not.

CVE-2025-9141: eval() on Tool Calls

vLLM, the most widely deployed open-source inference engine, had CVE-2025-9141 — an arbitrary code execution vulnerability in its XML-based tool parser for Qwen3 Coder. The parser passed almost every tool-call argument to Python's eval(). The entire attack surface looked like this:

# Rough sketch of the vulnerable pattern
def parse_tool_call(xml_string):
    params = extract_params(xml_string)
    return eval(f"{{{params}}}")  # Arbitrary code execution

Here's the part that should make you angry: Gemini automatically analyzed the PR that introduced this bug and flagged it as a critical security vulnerability. The lead maintainer of vLLM force-merged it anyway. Their justification: "parsing an arbitrary token sequence into a fully fledged chat (with user turns, assistant responses, tool calls, and so on) is not trivial."

"Parsing is not trivial" is not a defense for shipping arbitrary code execution to every vLLM deployment. It's an admission that the engine's architecture was built without the threat model of its own output in mind.

This Is Not One Bug. It's a Class of Bugs.

Kane documents another case from a vLLM issue tracker where the engine parsed the plain string <mm:think> as the start of a reasoning block. Instead of returning it verbatim to the user, vLLM's parser injected it into the reasoning turn structure:

# What the model emitted:
I'll echo exactly what you said: <mm:think>
There, how was that?

# What vLLM returned:
I'll echo exactly what you said:
Reasoning: There, how was that?

This one is "harmless" — it doesn't execute code. But it demonstrates the depth of the problem. Modern inference engines are not simple token-to-string mappers. They are full protocol parsers that handle:

• 200+ model architectures, each with different chat templates and special tokens
• ~35 Jinja chat templates for formatting turns, tool calls, and reasoning blocks
• Tool-call schema parsing across JSON, XML, and custom formats
• Multimodal output decoding — tokens → pixels/audio through model-specific decoders, then through ffmpeg/encoders
• Grammar-constrained generation — regex/BNF enforcement that can introduce its own parsing paths

Every one of these is an input parser. Every parser reads tokens produced by an LLM. Every parser that trusts its input is a vulnerability waiting to be triggered.

The Attack Surface Visually

graph TD
    subgraph "Attack Chain"
        A[LLM generates
crafted token sequence] --> B[Token parser
misinterprets as code]
        B --> C[Arbitrary code execution
on inference host]
        C --> D[Weight exfiltration /
host compromise]
    end
    subgraph "Defense Surface"
        E[GPU host] -->|"logits only"| F[Token parser host]
        F --> G[Agent harness]
    end
    style A fill:#991b1b,stroke:#dc2626
    style C fill:#991b1b,stroke:#dc2626
    style E fill:#1e3a5f,stroke:#3b82f6
    style F fill:#1e3a5f,stroke:#3b82f6

The GPU host and the token parser are usually the same machine. That's the architectural decision that makes this attack viable: the machine with direct access to the model's weights is also running the code that does eval() on model output.

Why This Matters Now

Three trends converge to make this more than theoretical:

1. Open-weight models are frontier-capable. Qwen 3.8 27B, running on consumer hardware, can reverse-engineer binaries and write multi-step analyses. The question "can an LLM craft the right token sequence to exploit a parser bug" changes from "probably not" to "give it the right context and try."
2. Inference engines are under constant pressure to be faster. The vLLM codebase is a whirlwind of PRs for new architectures, attention backends, and quantizations. Every new feature expands the parsing surface. The vLLM-team maintainer's "parsing is not trivial" comment is brutally honest — but it's an argument against trusting the parser with untrusted input, not an excuse for shipping eval().
3. Tool use makes exploits reproducible and persistent. If an agent discovers an exploit token sequence, it can store that sequence in a file — and any other agent that reads that file will trigger the exploit just by having the tokens enter its context. Prompt injection meets operational security.

What We Should Do About It

Kane proposes two architectural mitigations that are worth implementing now, not after the first major exploit:

• Separate the GPU host from the token parser. One machine runs the model forward pass and emits logits. A second, air-gapped machine samples tokens, parses them into responses, and forwards to the agent harness. A parser compromise on the second machine doesn't give the attacker access to the GPU server with the weights and the datacenter network.
• Treat all data from the inference engine as untrusted. If the GPU host is a single machine, run the parser in a separate process with minimal permissions — no access to model weights, no network access beyond the agent harness, no filesystem write access.

I'd add a third: fuzz your chat templates and tool parsers with adversarial token sequences before deployment. Generate random token sequences, pass them through your inference engine, and check whether any of them get interpreted as control flow. The MiniMax-M3 bug would have been caught in ten minutes of fuzzing.

Bottom Line

We've spent the last two years building agent harnesses to protect users from LLMs. We've spent almost no time protecting the inference engine from the LLM it's running. The threat model is inverted: the model is the attacker, and the engine that loads it is the target. CVE-2025-9141 is the proof that this attack surface is real, that it was shipped despite an automated security warning, and that it will happen again.

If you're running vLLM, SGLang, or any inference engine that parses model output back into structured data, check your parsers today. Assume every token the model emits is a vector.