CVE-2025-9141: 
Chainguard vulnerability analysis and mitigation

CVE-2025-9141 is a remote code execution (RCE) vulnerability in vLLM's Qwen3-Coder tool call parser that allows authenticated users to execute arbitrary code on the server. The flaw affects vLLM versions >= 0.10.0 and < 0.10.1.1, introduced when the Qwen3CoderToolParser was merged in July 2025. It was publicly disclosed on August 20, 2025, with a patch released the same day. The vulnerability carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Red Hat).

The root cause is the use of Python's eval() function within the qwen3coder_tool_parser.py module to parse tool call parameters when the parameter type is not explicitly defined or recognized (CWE-502: Deserialization of Untrusted Data). The vulnerable code path is only reachable when vLLM is started with both --enable-auto-tool-choice and --tool-call-parser qwen3_coder flags. An attacker with low-privilege API access can craft a prompt that causes the Qwen3-Coder model to emit a tool call response containing a malicious Python expression as a parameter value, which is then passed directly to eval() on the server. Notably, the Gemini code-assist bot flagged this exact eval() usage as a critical security vulnerability during the original pull request review, but the PR was force-merged without addressing it (GitHub PR #21396, GitHub Advisory).

Successful exploitation grants an attacker full remote code execution on the vLLM server process, resulting in high impact to confidentiality, integrity, and availability. An attacker can read sensitive data (model weights, API keys, environment variables), modify server state or hosted model behavior, and disrupt service availability. Because vLLM servers often run in AI/ML infrastructure with broad network access, exploitation could facilitate lateral movement into adjacent systems or cloud environments (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). Exploitation requires low-privilege authenticated access to the vLLM API and the server must be configured with both --enable-auto-tool-choice and --tool-call-parser qwen3_coder. The attack complexity is low once these preconditions are met, as the attacker only needs to craft a prompt that induces the model to output a malicious tool call parameter. The CVE is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no EPSS score is publicly available yet (GitHub Advisory).

1. Reconnaissance: Identify vLLM API endpoints (typically port 8000) running versions >= 0.10.0 and < 0.10.1.1 with the Qwen3-Coder model loaded and tool calling enabled (--enable-auto-tool-choice --tool-call-parser qwen3_coder).
2. Authenticate: Obtain or use existing low-privilege API credentials to access the vLLM OpenAI-compatible API endpoint.
3. Craft malicious prompt: Construct a chat completion request that includes a tool definition with a parameter of an unrecognized or ambiguous type, and a user message designed to induce the model to return a tool call where the parameter value contains a malicious Python expression (e.g., __import__('os').system('id')).
4. Submit request: Send the crafted API request to /v1/chat/completions with the tool definition and prompt payload.
5. Trigger eval(): The Qwen3-Coder model generates a tool call response with the attacker-controlled parameter value; the parser's eval() call executes the embedded Python expression on the server.
6. Achieve RCE: The arbitrary Python code executes in the context of the vLLM server process, enabling reverse shell establishment, data exfiltration, or further lateral movement (GitHub Advisory, GitHub PR #21396).

• Network: Unexpected outbound connections from the vLLM server process to external IPs or unusual internal hosts following API requests; anomalous DNS lookups initiated by the vLLM process.
• Logs: vLLM access logs showing API calls to /v1/chat/completions with tool definitions containing unusual parameter types; warning log entries matching "cannot be converted via Python eval()" in vLLM application logs, which may indicate probing attempts.
• Process: Unexpected child processes spawned by the vLLM Python process (e.g., sh, bash, curl, wget, python3) visible via process tree inspection; unusual system calls from the vLLM process.
• File System: New files or scripts written to the vLLM working directory or /tmp; unexpected modifications to configuration files or model artifacts by the vLLM service account.

Upgrade vLLM to version 0.10.1.1 or later, which removes the unsafe eval() call from the Qwen3-Coder tool parser (GitHub Advisory). As an immediate workaround for deployments that cannot upgrade, avoid starting vLLM with both --enable-auto-tool-choice and --tool-call-parser qwen3_coder simultaneously. Additionally, restrict API access to trusted, authenticated users only, apply network-level controls to limit exposure of the vLLM API endpoint, and monitor for suspicious process activity from the vLLM server process (Red Hat).

The vulnerability was flagged during the original pull request code review by the Gemini code-assist bot, which explicitly identified the eval() usage as a "critical security vulnerability" and recommended its removal — however, the PR was force-merged without addressing this feedback (GitHub PR #21396). The case has drawn attention as an example of AI-assisted code review catching a security flaw that human reviewers missed or deprioritized under time pressure. Community discussion appeared on platforms including Bluesky and Lemmy following disclosure (Feedly).