An LLM's own output can exploit vLLM and run code on its host
CVE-2025-9141 piped Qwen3-Coder tool args into eval(). A widely-shared essay names vLLM and SGLang as the real attack surface — and how to wall yours off.
Copy markdown
The proof: CVE-2025-9141 sent tool args to eval()
vLLM's Qwen3-Coder tool-call parser fell back to Python's eval() for any argument whose type it didn't recognize — a remote code execution hole rated 8.8. Any authenticated caller hitting a server started with --enable-auto-tool-choice --tool-call-parser qwen3_coder could run code on the GPU box. Fixed in vLLM 0.10.1.1; anything from 0.10.0 up is exposed.
Why it generalizes: 200+ parsers you never audited
The essay's argument: vLLM supports 200-plus model architectures, each with its own chat and tool-call template, and every parser is a place a crafted token stream can break out. SGLang carries the same risk. Worse, a malicious sequence can be stashed in a file or URL to re-infect the next model instance that reads it.
The fix: put the parser on a different machine
Recommended hardening: run token parsing on a host separate from the GPU, lock down permissions there, and treat everything an inference server emits as untrusted input. If you build agents, sandbox tool-call execution and keep the model's raw output off any path with shell or eval access.