An AI model could hijack the server it runs on. A real bug already showed how.

A bug inside vLLM, a widely used open-source system that serves AI models on production GPUs, once let a model's own output run as code on the very machine holding its weights. The path was short: a tool-call parser for Qwen3 Coder passed almost every argument straight to Python's eval(), the language's built-in function for executing code from a string. The bug is now tracked as CVE-2025-9141, a Common Vulnerabilities and Exposures identifier under the standard naming scheme for publicly disclosed security flaws, and the way it got into the codebase is part of why it matters.

The introducing pull request carried an automated "critical severity" tag from Gemini, an AI code-review tool. The vLLM lead maintainer force-merged it anyway. As security researcher Boyd Kane writes, that decision is the evidence, not the hook: the change went into a parser, a piece of software whose entire job is to read what a model says and turn it into something a computer can act on. The fact that almost no one looked at it as security-critical code is the structural problem.

To see why, walk through what an inference engine does. When a model like Qwen3 Coder generates a response, it emits a stream of tokens, numbers that together spell out text. That text often needs to be parsed back into a chat message, a tool call, or a structured object the application can use. vLLM documents support for more than 200 model architectures and ships an examples directory with roughly three dozen chat templates that shape how each model speaks. Every one of those parsers and templates sits between a model's output and the host machine. SGLang, a comparable open-source serving engine, faces the same exposure.

A malicious or prompt-injected model can emit a token sequence whose semantic content is irrelevant; the danger is in how it gets parsed. CVE-2025-9141 used eval() because that is the easiest way to turn a string into a Python value, and the easiest way to write a parser is rarely the safest. Five separate vulnerability databases, vLLM's own GitHub advisory, Snyk, CIRCL, GitLab's GLAD database, and Miggo, now record the same flaw.

The host running inference is not a random internet box. It holds the model's weights, the GPU doing the work, and a position inside the datacenter that lets it reach other services, customers, and code. A parser bug on that machine is a higher-severity event than the same bug on a generic web server, and the open-source ecosystem that builds inference engines has not been funded or staffed to match that reality. Discussion on Hacker News picked apart the fix and the threat model, including a contrarian view that any model capable of finding a parsing bug is also capable of much worse. Either way, the path between model output and system action is software, and software needs review.

Three things follow. Inference engines should be treated as security-critical infrastructure, on par with a database or a hypervisor, and staffed accordingly. Dynamic-execution patterns like eval() should be removed from parsing paths; the Qwen3 Coder parser is a cautionary example, not a unique failure. The roughly 200 model architectures and the three dozen chat templates vLLM already supports need an audit pass with a security lens, and so do the equivalent surfaces in SGLang and any other engine that takes raw model output and runs it through a parser before acting on it.

Red-teaming a model tells you what it will say; it does not tell you what a parser will do with what it says. The fix is better review, fewer eval() calls, and a recognition that the box running the model is the box an attacker most wants to reach.