CVE-2026-61539

GHSA-x2rj-828p-hx9m CRITICAL
Published August 21, 2026

### Summary Xinference used Python's unsafe `eval()` function when parsing Llama3 tool-call output generated by a large language model. Because the model output can be influenced by attacker-controlled prompts sent to the chat completion API, a remote attacker can craft prompts that cause the...

Full CISO analysis pending enrichment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
OpenAI Node pip <= 2.5.0 2.7.0
11.1K 311 dependents Pushed 6d ago 64% patched ~301d to patch Full package profile →

Do you use OpenAI Node? You're affected.

How severe is it?

CVSS 3.1
10.0 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
N/A

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Changed
C High
I High
A High

What should I do?

Patch available

Update OpenAI Node to version 2.7.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-61539?

### Summary Xinference used Python's unsafe `eval()` function when parsing Llama3 tool-call output generated by a large language model. Because the model output can be influenced by attacker-controlled prompts sent to the chat completion API, a remote attacker can craft prompts that cause the model to return a Python expression. Xinference then evaluates that expression on the server while post-processing the tool-call result. In the tested default deployment, authentication was not enabled, so the vulnerability was exploitable by an unauthenticated remote attacker through the `/v1/chat/completions` endpoint. ### Details Users can interact with deployed models through Xinference's OpenAI-compatible `/v1/chat/completions` API. The request entry point is implemented in `xinference/api/restful_api.py`; non-streaming requests call the model instance's `chat()` method and return the inference result. When the Transformers backend is used, inference results flow through the batching logic in `xinference/model/llm/transformers/core.py`. Non-streaming chat results are handled by `handle_chat_result_non_streaming()`. If the request contains a `tools` field, Xinference calls `_post_process_completion()` to parse tool-call output from the model response. The Llama3 tool-call parser is implemented in `xinference/model/llm/tool_parsers/llama3_tool_parser.py`. In affected versions, `extract_tool_calls()` parsed model output with `eval()`: ```python def extract_tool_calls( self, model_output: str ) -> List[Tuple[Optional[str], Optional[str], Optional[Dict[str, Any]]]]: try: data = eval(model_output, {}, {}) return [(None, data["name"], data["parameters"])] except Exception: return [(model_output, None, None)] ``` The intended behavior was to convert a Python dictionary-like string generated by the model into a dictionary object. However, `eval()` executes the input as a Python expression, and `eval(model_output, {}, {})` is not a security sandbox. If an attacker can influence the model output through prompt injection or direct chat input, the attacker can cause the model to return an expression such as: ```python __import__('os').system('touch /tmp/hacked') ``` When the expression reaches `eval()`, it is executed in the Xinference server process context. The harmless `touch /tmp/hacked` command can be replaced with other payloads, such as a reverse shell, malware download, sensitive file read, or lateral-movement payload. ### Score Severity: Critical CVSS v3.1: 10.0 Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` Rationale: - AV:N: the vulnerable API is remotely reachable over the network; - AC:L: exploitation only requires a crafted chat-completion request and tool-call parameter; - PR:N: the tested default configuration did not require authentication; - UI:N: no user interaction is required; - S:C: command execution can affect resources beyond the Xinference application boundary; - C:H/I:H/A:H: remote code execution can fully compromise confidentiality, integrity, and availability. ### Credit This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com) - Atuin Automated Vulnerability Discovery Engine - Guannan Wang (wgnbuaa@gmail.com), Zhanpeng Liu (pkugenuine@gmail.com), Guancheng Li (lgcpku@gmail.com)

Is CVE-2026-61539 actively exploited?

No confirmed active exploitation of CVE-2026-61539 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-61539?

Update to patched version: OpenAI Node 2.7.0.

What is the CVSS score for CVE-2026-61539?

CVE-2026-61539 has a CVSS v3.1 base score of 10.0 (CRITICAL).

What are the technical details?

Original Advisory

### Summary Xinference used Python's unsafe `eval()` function when parsing Llama3 tool-call output generated by a large language model. Because the model output can be influenced by attacker-controlled prompts sent to the chat completion API, a remote attacker can craft prompts that cause the model to return a Python expression. Xinference then evaluates that expression on the server while post-processing the tool-call result. In the tested default deployment, authentication was not enabled, so the vulnerability was exploitable by an unauthenticated remote attacker through the `/v1/chat/completions` endpoint. ### Details Users can interact with deployed models through Xinference's OpenAI-compatible `/v1/chat/completions` API. The request entry point is implemented in `xinference/api/restful_api.py`; non-streaming requests call the model instance's `chat()` method and return the inference result. When the Transformers backend is used, inference results flow through the batching logic in `xinference/model/llm/transformers/core.py`. Non-streaming chat results are handled by `handle_chat_result_non_streaming()`. If the request contains a `tools` field, Xinference calls `_post_process_completion()` to parse tool-call output from the model response. The Llama3 tool-call parser is implemented in `xinference/model/llm/tool_parsers/llama3_tool_parser.py`. In affected versions, `extract_tool_calls()` parsed model output with `eval()`: ```python def extract_tool_calls( self, model_output: str ) -> List[Tuple[Optional[str], Optional[str], Optional[Dict[str, Any]]]]: try: data = eval(model_output, {}, {}) return [(None, data["name"], data["parameters"])] except Exception: return [(model_output, None, None)] ``` The intended behavior was to convert a Python dictionary-like string generated by the model into a dictionary object. However, `eval()` executes the input as a Python expression, and `eval(model_output, {}, {})` is not a security sandbox. If an attacker can influence the model output through prompt injection or direct chat input, the attacker can cause the model to return an expression such as: ```python __import__('os').system('touch /tmp/hacked') ``` When the expression reaches `eval()`, it is executed in the Xinference server process context. The harmless `touch /tmp/hacked` command can be replaced with other payloads, such as a reverse shell, malware download, sensitive file read, or lateral-movement payload. ### Score Severity: Critical CVSS v3.1: 10.0 Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` Rationale: - AV:N: the vulnerable API is remotely reachable over the network; - AC:L: exploitation only requires a crafted chat-completion request and tool-call parameter; - PR:N: the tested default configuration did not require authentication; - UI:N: no user interaction is required; - S:C: command execution can affect resources beyond the Xinference application boundary; - C:H/I:H/A:H: remote code execution can fully compromise confidentiality, integrity, and availability. ### Credit This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com) - Atuin Automated Vulnerability Discovery Engine - Guannan Wang (wgnbuaa@gmail.com), Zhanpeng Liu (pkugenuine@gmail.com), Guancheng Li (lgcpku@gmail.com)

Weaknesses (CWE)

CWE-95 — Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'): The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

  • [Architecture and Design, Implementation] If possible, refactor your code so that it does not need to use eval() at all.
  • [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Timeline

Published
August 21, 2026
Last Modified
August 21, 2026
First Seen
August 22, 2026

Related Vulnerabilities