CVE-2026-76841: Xinference: RCE via forced trust_remote_code=True
HIGHPoC AVAILABLEXinference, 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.
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?
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade 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?
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:
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
MITRE ATLAS Techniques
AML.T0011.000Unsafe AI ArtifactsAML.T0018.002Embed MalwareAML.T0050Command and Scripting InterpreterAML.T0112Machine CompromiseCompliance Controls Affected
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:HReferences
- github.com/xorbitsai/inference
- github.com/xorbitsai/inference/blob/v2.11.0/xinference/model/rerank/core.py
- github.com/xorbitsai/inference/issues/5023
- github.com/xorbitsai/inference/pull/5027
- vulncheck.com/advisories/xinference-through-remote-code-execution-via-hardcoded-trust-remote-code-in-model-loaders
Timeline
Related Vulnerabilities
CVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply ChainCVE-2024-291210.0BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply ChainCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Supply ChainCVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply ChainCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution