Xinference CVE-2026-76841: a Hugging Face model was an executable dependency
Six loaders trusted model remote code. Analysis of trust_remote_code, version 2.12.0, model-launch privileges and AI worker isolation.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 24 August 2026
- READING TIME
- 19 min read
- TOPIC
- AI Security
CVE-2026-76841 was published on 24 August and affects Xinference before version 2.12.0. Six model-loading paths either hardcoded Hugging Face trust_remote_code=True or left it enabled by default. A user with permission to launch a model could register an unknown family and select a controlled repository, after which a loader imported Python code declared by model metadata.
The result is remote code execution in a worker process. The record assigns CVSS 4.0: 8.7 (High) and CVSS 3.1: 8.8 (High). The fix is in Xinference 2.12.0, released on 4 July. Its most important change is not improved scanning of a model file, but disabled trust in remote code for user models until an operator deliberately opts in.
A model is not always just a collection of weights
System diagrams often present an AI model as data: weight tensors, a tokenizer and configuration. The Hugging Face ecosystem also supports architectures that need a custom implementation. Through auto_map in tokenizer_config.json, a repository can name a Python class that the library should retrieve and import. trust_remote_code=True is consent to execute that implementation.
The feature has legitimate uses. It allows new architectures to run before they enter the standard Transformers library. From a security perspective, however, the model repository becomes equivalent to a code package or container image. Its author, commit and contents need a software-supply-chain level of trust.
In the affected Xinference path, a user could register an unknown model and control its location. Automatic type detection reached AutoTokenizer.from_pretrained(). After reading auto_map, the library loaded a class from the repository, and importing it executed code inside the worker. This is not prompt injection or a problem with an LLM response; it is ordinary Python execution while preparing a model.
Six locations, one policy failure
The advisory and fix identify six loaders: rerank paths, Sentence Transformers embedding and rerank paths, FlagEmbedding integration, and two Transformers LLM paths. Distribution mattered because repairing one call would have left another route to the same dangerous feature.
The common issue was not a particular model architecture but absence of a central policy decision. Each loader locally assumed that remote code was acceptable. As a platform adds backends, copied defaults drift and become difficult to audit. A safer design calculates consent once from model provenance and an operator setting, while a loader only consumes that decision.
The fix adds XINFERENCE_TRUST_REMOTE_CODE, disabled by default, and a common function for deciding consent. Built-in integrations can keep working based on trusted provenance (is_builtin), while user models require explicit operator opt-in. This separates the convenience of a controlled catalogue from the risk of an arbitrary user-supplied location.
“Launch model” becomes a code-execution privilege
An organisation may assume a role allowed to launch models consumes only GPU and memory. With remote code enabled, the same role can select code executed by a worker. RBAC should therefore treat custom-model registration, repository selection and changing the trust flag as administrative actions comparable to application deployment.
In a multi-tenant environment, impact depends on isolation. A worker may hold a Hugging Face token, storage keys, access to other models, a shared cache volume and network paths to internal services. If tenants share a process or directory, one user’s code can read another’s resources. A separate process without secrets limits some effects; a separate sandbox or node with its own identity limits more.
This does not mean every Hugging Face model is malicious or that a standard weights file automatically executes code. The risk concerns paths permitting a remote implementation from provenance the operator has not verified. Built-in models pinned to an approved commit should be distinguished from an arbitrary name or path supplied by a user.
Updating and configuring safely
Update Xinference to 2.12.0 or a later supported release. After deployment, check the coordinator and every worker; an old worker left behind may continue serving a job through a vulnerable loader. Restart processes in a controlled way and remove old images from active scheduling so autoscaling cannot restore an incorrect release.
Keep XINFERENCE_TRUST_REMOTE_CODE disabled unless a documented need exists. If a specific model genuinely requires a custom class, do not enable global trust without other boundaries. Verify repository ownership, pin an immutable commit or digest, review the code, record approval and run the model in a separate worker pool.
An allowlist should bind a logical model name to an exact source, revision, artifact hash and expected loader. An organisation name in a URL is not an integrity control. Mirror approved artifacts into an internal registry, sign the manifest and prohibit resolving a moving main branch in production.
Containing the AI worker
A worker loading external models should use a minimal identity, with no control-plane credentials or secrets from other tenants. Its filesystem can be read-only outside a controlled cache, and cache partitions should follow trust domains. Remove unnecessary container capabilities, syscalls, runtime sockets and host-path mounts.
Egress should reach only an approved mirror and required services. If a worker can contact cloud metadata, a database, a Kubernetes control plane and the whole Internet, one import receives broad reach. Prefer short-lived workload identities over static keys in environment variables.
A GPU does not provide isolation by itself. Code that prepares a tokenizer and model executes on the CPU in an ordinary process before inference starts. Containers are also not a complete boundary between hostile tenants without a correct profile, limits, separate credentials and an up-to-date runtime. Models requiring remote code deserve a dedicated pool with a hardened profile.
Detection and historical review
Inventory custom-model registrations and every launch during the period when a version before 2.12.0 was active. Record the user, time, source, revision, family, worker and auto-detection result for each. Prioritise unknown repositories, moving revisions, user-controlled private paths and models that downloaded additional Python files.
In worker logs, look for dynamic imports, .py downloads, auto_map class errors, new child processes, cache changes, environment-variable access and unusual connections. Compare cache contents with the approved commit. A repository may have changed since launch, so its current upstream state does not prove what a worker downloaded earlier.
If unapproved code execution is confirmed, isolate the worker, preserve artifacts and telemetry, then rebuild it. Rotate credentials that the process could read and inspect systems reachable through its identity. Review other jobs using the same cache or image as well.
Lessons for the AI supply chain
An application SBOM does not automatically include code retrieved while loading a model. Organisations need a model manifest containing source, revision, format, custom code, licence and the trust decision. That manifest should follow the same promotion process between development, staging and production as a software dependency.
Separate roles: a researcher may propose a model, a security or platform team approves its provenance, and the production orchestrator launches only the catalogued release. Telemetry should expose not just model_name, but the effective commit and remote-code state. Otherwise an incident responder cannot reconstruct which code ran at a given time.
Source facts and Breachroad conclusions
The pre-2.12.0 scope, six loaders, auto_map path, RCE capability and CVSS scores come from the CVE record and VulnCheck advisory. The disabled-by-default setting, built-in-model exception and common policy function come from the project pull request. Public materials used here do not confirm active exploitation.
The permission model, worker isolation, model manifest, cache analysis and response sequence are Breachroad conclusions. AI security training for organisations helps teams govern models and agents safely, while application and API security assessments can validate RBAC, registries and execution boundaries in an AI platform.
