vLLM OpenAI-compatible server (qwen3_coder tool-call parser): Code execution inside the serving process, which on a GPU

Impact

Code execution inside the serving process, which on a GPU node means execution next to the model weights, the GPU, and whatever credentials the inference pod holds. vLLM's Qwen3-Coder tool parser falls back to Python eval() when converting a tool-call parameter whose type it does not recognise. Any authenticated API user who can steer the model into emitting a crafted argument gets that string evaluated on the server. For an inference provider this is the worst shape of the multi-tenant problem: one customer's prompt reaches the interpreter on a box that is simultaneously serving other customers' requests, giving access to in-flight prompts and completions, the model artifacts on local disk, and the node's service-account token and cloud identity. Prompt content is attacker-controlled by definition in a serving product, so the 'requires authentication' qualifier buys very little.

Who can reach it

Network, any authenticated API client. Requires the server to be started with --enable-auto-tool-choice and --tool-call-parser qwen3_coder; the payload arrives as an ordinary completion request whose tool-call parameters carry an unrecognised type.

What to do

Upgrade vLLM to 0.10.1.1 or later and restart the serving processes. If you cannot upgrade immediately, stop the server with the qwen3_coder parser or disable automatic tool choice — that removes the code path entirely. Longer term, run inference pods with a scoped service account and no ambient cloud credentials so an eval() foothold does not become a cluster foothold.

References