Hugging Face Transformers RCE Flaw Can Run Code Through Malicious Model Configs

A newly disclosed Hugging Face Transformers vulnerability can let attackers run code on a victim’s system when a malicious model is loaded through a normal model-loading workflow.

The flaw is tracked as CVE-2026-4372 and affects the popular Transformers machine learning library. According to the NVD entry, the issue allows a malicious model configuration file to point the library toward attacker-controlled code that can execute with the victim’s operating system privileges.

Security firm Pluto Security, which disclosed the issue publicly on June 4, said the bug can bypass the trust_remote_code=False protection many developers rely on when loading models from Hugging Face Hub. The Pluto Security research said the attack requires a victim to load a malicious model, but does not require the victim to explicitly approve remote code execution.

How CVE-2026-4372 works

The vulnerability centers on model configuration data. A malicious model can include a crafted config.json file that uses an internal attention implementation field to reference an attacker-controlled Hugging Face Hub repository.

When a vulnerable Transformers installation loads that model, the library can fetch and import code through the kernels integration path. Hugging Face documentation says the kernels library lets optimized compute kernels load directly from the Hub, which helps developers use faster attention implementations without manually compiling them.

That design created risk when internal configuration fields were not filtered tightly enough. The attacker did not need to hide code inside a traditional software package. The malicious instruction could sit inside a model’s configuration and trigger during a routine model load.

Detail	Information
CVE ID	CVE-2026-4372
Affected product	Hugging Face Transformers
Vulnerability type	Remote code execution through model configuration injection
CNA severity	High, CVSS 7.8
Fixed version	Transformers 5.3.0 or later
Main risk	Execution of attacker-controlled Python code during model loading

The flaw bypassed a key safety control

The most important detail is the trust_remote_code bypass. Developers often keep trust_remote_code=False to avoid executing custom code from untrusted model repositories.

In this case, the vulnerable path did not depend on the user enabling that setting. The CVE record says the vulnerability bypasses the trust_remote_code security mechanism and exploits a standard documented usage pattern.

That makes the bug dangerous for AI teams that followed normal security guidance. A developer could believe remote code execution was disabled, then load a model that silently triggered code through the kernel-loading path.

• The attack starts with a malicious model repository.
• The victim loads the model using a common Transformers workflow.
• The malicious configuration points to attacker-controlled code.
• The vulnerable library imports and runs that code without the expected warning.
• The attacker may gain access to files, secrets, tokens, and development environments.

Which Transformers versions are affected?

Pluto Security said the exploitable kernel-dispatch path affected Transformers versions 4.56.0 through 5.2.x when the optional kernels package was installed. The bug was introduced in late August 2025 and fixed in March 2026, according to the technical disclosure.

The public vulnerability record takes a broader view and lists Transformers versions before 5.3.0 as affected. For security teams, the practical answer is simple: upgrade to Transformers 5.3.0 or newer, especially in environments that load models from external sources.

The fix appears in a Hugging Face Transformers commit titled “fix security vuln.” The GitHub patch blocks problematic internal configuration fields from being deserialized and restricts kernel loading to a trusted repository namespace.

Why AI supply chains are exposed

Machine learning teams often treat models, weights, and configuration files as data. CVE-2026-4372 shows why that assumption can fail when model loading frameworks support dynamic code paths.

The risk is especially high in automated AI pipelines. A CI job, notebook, training cluster, or evaluation script may pull models from public repositories and load them as part of a normal workflow. If that environment contains cloud credentials, SSH keys, API tokens, or private datasets, a successful attack can have a broad impact.

The Transformers PyPI page describes the library as a model-definition framework for text, computer vision, audio, video, and multimodal models. That wide scope explains why a model-loading flaw can affect many different AI workflows, not only chatbot projects.

Environment	Potential impact
Developer laptop	Local files, SSH keys, and cloud credentials may be exposed
CI/CD pipeline	Build secrets, deployment tokens, and source code may be at risk
Training cluster	Private datasets and model artifacts may be accessed
Production inference server	Service credentials and connected systems may be compromised

Hugging Face patched the vulnerable path

The fix adds stricter handling for internal configuration attributes and changes how hub kernels are accepted. In the Hugging Face commit, the project blocks deserialization of internal attention and experts implementation fields from Hub configs.

The patch also updates kernel validation. Comments in the code explain that, for security reasons, Transformers should only accept kernels from the kernels-community repository, because loading random kernels can lead to arbitrary code execution.

Hugging Face’s kernels documentation shows why the feature exists: pre-optimized kernels can improve training and inference performance. The vulnerability shows that performance-oriented extensibility needs equally strong trust boundaries.

What organizations should do now

Organizations using Hugging Face Transformers should upgrade to version 5.3.0 or later. Teams should also check whether vulnerable versions were used in notebooks, CI jobs, model evaluation systems, and production inference workloads.

Security teams should audit models downloaded during the exposure period, especially models from new, unknown, or lightly reviewed repositories. They should also review logs for unusual outbound connections from AI development systems and build agents.

The Transformers package remains a core part of the AI ecosystem, but this incident shows why teams should treat model loading as a software supply-chain event, not a passive data operation.

• Upgrade Transformers to 5.3.0 or later.
• Identify systems that loaded public models while running vulnerable versions.
• Rotate secrets from environments that may have loaded untrusted models.
• Run model evaluation in isolated containers or sandboxes.
• Limit outbound network access from training and CI environments.
• Pin trusted model repositories and review model configuration files before use.

Why this matters for AI developers

CVE-2026-4372 does not require attackers to compromise Hugging Face itself. A threat actor can create a malicious model repository and wait for users or automated workflows to load it.

That is why model provenance now matters as much as package provenance. Developers should check who published a model, how long the repository has existed, whether the files changed recently, and whether the model requires custom code or unusual kernel behavior.

The larger lesson is clear: AI model files can carry software risk. As companies bring more open models into internal workflows, they need package-style security reviews, network isolation, secret management, and runtime monitoring for AI pipelines.

FAQ