CVE-2026-76841: Xinference: RCE via forced trust_remote_code=True

HIGHPoC AVAILABLE
Published August 24, 2026
CISO Take

Xinference, a popular open-source model serving platform for LLMs, embeddings and rerankers, hardcodes trust_remote_code=True across six loader call sites, meaning any user with model-launch access can register a model pointing to an attacker-controlled path and have the server execute arbitrary Python declared in that model's tokenizer_config.json auto_map. This is a network-exploitable, low-complexity CVSS 8.8 flaw with no user interaction required — a low-privileged API caller becomes full code execution on the inference worker, which is a severe blast radius for any team running Xinference as a shared model-serving backend behind RAG, agent, or embedding pipelines. There's no public exploit or Nuclei template yet and it isn't in CISA KEV, but the vulnerability class (Hugging Face trust_remote_code abuse) is well-documented and trivially weaponizable once an attacker has model registration rights. Patch to Xinference 2.12.0 or later, which gates all six sites behind allow_trust_remote_code and the XINFERENCE_TRUST_REMOTE_CODE setting; until patched, restrict model-launch API access to trusted operators only and block registration of models from arbitrary/untrusted paths.

Sources:NVDGitHubATLASvulncheck.com

What is the risk?

High risk in practice despite the absence of active exploitation or public PoC. The attack requires only low privileges (model launch access, which is often granted broadly to internal ML engineers or via shared API keys) and no user interaction, with network attack vector and low complexity. The vulnerability sits at a very common trust boundary in self-hosted LLM infrastructure: anyone who can point the server at a model path controls what code runs. Because trust_remote_code was hardcoded True rather than opt-in, exploitation doesn't require a misconfiguration — it is the default, unsafe behavior of six separate code paths (rerank, embedding via sentence-transformers and FlagEmbedding, and PyTorch LLM loading). This significantly widens exposure versus a single-function bug.

How does the attack unfold?

Initial Access
An attacker with model-launch API access (compromised key, insider, or overly permissive shared credentials) registers a new model pointing to an attacker-controlled path.
AML.T0011.000
Malicious Artifact Staging
The attacker crafts a tokenizer_config.json with an auto_map declaring Python classes designed to execute arbitrary code on import.
AML.T0018.002
Exploitation
Xinference's hardcoded trust_remote_code=True causes AutoTokenizer.from_pretrained to import and execute the attacker's code during model load.
AML.T0050
Impact
Arbitrary code runs with the privileges of the worker process, giving the attacker control of the inference server and a foothold into connected AI infrastructure.
AML.T0112

How severe is it?

CVSS 3.1
8.8 / 10
EPSS
1.0%
chance of exploitation in 30 days
Higher than 64% 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
PRLow
UINone
SUnchanged
CHigh
IHigh
AHigh

What should I do?

1 step
  1. Upgrade to Xinference >= 2.12.0, which introduces allow_trust_remote_code and the XINFERENCE_TRUST_REMOTE_CODE setting and restricts remote code execution to bundled built-in models only. If immediate upgrade isn't possible: restrict model-launch API access to trusted, authenticated operators only (treat it as an admin-equivalent capability, not a general user capability); disallow registration of custom models pointing at arbitrary or user-supplied paths; run Xinference workers in a sandboxed/isolated environment (container with minimal privileges, no access to sensitive secrets or lateral network paths) so that code execution in the worker has limited blast radius. For detection, audit model registration events for unexpected model paths/types and monitor worker processes for unexpected child process spawns or outbound network connections following a model launch.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
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.6-AI system security requirements
NIST AI RMF
MEASURE 2.7-AI system security and resilience is evaluated and documented
OWASP LLM Top 10
LLM05:2025-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-76841?

Xinference, a popular open-source model serving platform for LLMs, embeddings and rerankers, hardcodes trust_remote_code=True across six loader call sites, meaning any user with model-launch access can register a model pointing to an attacker-controlled path and have the server execute arbitrary Python declared in that model's tokenizer_config.json auto_map. This is a network-exploitable, low-complexity CVSS 8.8 flaw with no user interaction required — a low-privileged API caller becomes full code execution on the inference worker, which is a severe blast radius for any team running Xinference as a shared model-serving backend behind RAG, agent, or embedding pipelines. There's no public exploit or Nuclei template yet and it isn't in CISA KEV, but the vulnerability class (Hugging Face trust_remote_code abuse) is well-documented and trivially weaponizable once an attacker has model registration rights. Patch to Xinference 2.12.0 or later, which gates all six sites behind allow_trust_remote_code and the XINFERENCE_TRUST_REMOTE_CODE setting; until patched, restrict model-launch API access to trusted operators only and block registration of models from arbitrary/untrusted paths.

Is CVE-2026-76841 actively exploited?

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

How to fix CVE-2026-76841?

Upgrade to Xinference >= 2.12.0, which introduces allow_trust_remote_code and the XINFERENCE_TRUST_REMOTE_CODE setting and restricts remote code execution to bundled built-in models only. If immediate upgrade isn't possible: restrict model-launch API access to trusted, authenticated operators only (treat it as an admin-equivalent capability, not a general user capability); disallow registration of custom models pointing at arbitrary or user-supplied paths; run Xinference workers in a sandboxed/isolated environment (container with minimal privileges, no access to sensitive secrets or lateral network paths) so that code execution in the worker has limited blast radius. For detection, audit model registration events for unexpected model paths/types and monitor worker processes for unexpected child process spawns or outbound network connections following a model launch.

What systems are affected by CVE-2026-76841?

This vulnerability affects the following AI/ML architecture patterns: model serving, RAG pipelines, agent frameworks.

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

CVE-2026-76841 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 1.03%.

What is the AI security impact?

Affected AI Architectures

model servingRAG pipelinesagent frameworks

MITRE ATLAS Techniques

AML.T0011.000Unsafe AI Artifacts
AML.T0018.002Embed Malware
AML.T0050Command and Scripting Interpreter
AML.T0112Machine Compromise

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.6
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

Xinference loads models with Hugging Face remote code execution unconditionally enabled, and before version 2.12.0 exposes no setting to disable it. Six loader call sites pass trust_remote_code=True as a literal or as an unconditional default: RerankModel._get_tokenizer in xinference/model/rerank/core.py, SentenceTransformerRerankModel.load in xinference/model/rerank/sentence_transformers/core.py, SentenceTransformerEmbeddingModel.load in xinference/model/embedding/sentence_transformers/core.py, FlagEmbeddingModel.load in xinference/model/embedding/flag/core.py, and two sites in xinference/model/llm/transformers/core.py where PytorchModel._sanitize_model_config and PytorchModel._get_components default the value to True. Because a caller with model launch access can register a model whose type is unknown and supply an arbitrary model path, the server reaches _auto_detect_type and then AutoTokenizer.from_pretrained, which imports and executes Python declared by the model directory's own tokenizer_config.json auto_map, running attacker-supplied code with the privileges of the worker process. Version 2.12.0 gates every site behind allow_trust_remote_code and the XINFERENCE_TRUST_REMOTE_CODE setting, permitting remote code only for bundled built-in models.

Exploitation Scenario

An internal user or a party with a leaked/shared Xinference API key registers a new model of unspecified type, pointing model_path to a directory they control (e.g., a public Hugging Face repo or an internal path the attacker can write to) containing a crafted tokenizer_config.json with an auto_map referencing malicious Python classes. When the model is launched, Xinference's _auto_detect_type and subsequent AutoTokenizer.from_pretrained call reach one of the six loader sites that hardcode trust_remote_code=True, causing the server to import and execute the attacker's code with the privileges of the worker process — granting the attacker a foothold to exfiltrate data, pivot to connected systems (vector DBs, internal APIs), or establish persistence on the inference host.

Weaknesses (CWE)

CWE-94 — Improper Control of Generation of Code: The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

  • [Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
  • [Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.

CVSS Vector

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

Timeline

Published
August 24, 2026
Last Modified
October 1, 2026
First Seen
August 24, 2026

Related Vulnerabilities