For nine months, 25 percent of Transformers downloads were vulnerable to a one-click RCE that bypassed the library's only safety switch.
A hidden threat camouflaged as ornamentation in a manuscript, mirroring how attacker-controlled code can be concealed inside legitimate model files.
A remote code execution vulnerability sat in the Hugging Face Transformers library from August 2025 until March 3, 2026. It was patched silently in version 5.3.0 and assigned CVE-2026-4372 on May 24. The bug lets an attacker craft a model configuration file that downloads and runs arbitrary Python on the victim's machine. The attack works even when trust_remote_code is set to false, the flag that the entire ecosystem treats as the boundary between running code and loading inert data. That boundary was a fiction.
The Transformers library has 2.2 billion total installs and clocks 146 million monthly PyPI downloads, according to CSO Online. It is the default plumbing for loading open-weight models. For nine months, every researcher, startup, and enterprise running AutoModelForCausalLM.from_pretrained() on a model they did not personally author was exposed to a remote code execution vector that produced no warnings and left no unusual log entries.
A crumbling bridge being replaced by a single-lane fortified crossing, representing the forced migration from a trusted but vulnerable infrastructure to a more restrictive, bottlenecked alternative.
The earlier warning sign
This was not the first time unsafe deserialization burned a hole through the library. On January 12, 2026, Hugging Face merged PR #43140, a fix for an RCE in Trainers._load_rng_state. That bug allowed arbitrary code execution through malicious rng_state.pth files on PyTorch versions 2.2 through 2.5. The contributor, Cole Murray, wrote: "Users loading untrusted checkpoints on PyTorch 2.2-2.5 are vulnerable to arbitrary code execution via malicious rng_state.pth files." The fix landed. The assumption that model files are passive data persisted.
Two months later, a second RCE was patched. The pattern is not a coincidence. It is a structural consequence of building a model-loading ecosystem on top of Python's pickle serialization and a tangle of implicit trust assumptions.
How the exploit works
The vulnerability lives in how the Transformers library handles the config.json file that accompanies every model on the Hugging Face Hub. Researchers at Pluto Security found that an attacker can add a field called _attn_implementation_internal to that config file and set its value to a repository ID under the attacker's control.
When a victim loads the model using the standard AutoModelForCausalLM.from_pretrained() API, the library reads that field and downloads whatever code sits in the attacker's repo. It executes that code with the victim's full OS privileges. There is no prompt. There is no consent dialog. The field uses an underscore prefix that makes it indistinguishable from the dozens of internal implementation details that legitimate config files contain. Pluto Security told CSO Online: "The malicious field uses an underscore-prefixed name that looks like an internal implementation detail — the kind of field that config files are full of. There are no runtime warnings, no consent prompts, no unusual log entries."
The Tenable CVE description confirms the mechanics: "This issue arises due to unfiltered deserialization of configuration attributes, insufficient sanitization of internal fields, and unsandboxed execution of downloaded kernels." The CVSS v3 base score is 7.8, High severity. The EPSS score, which estimates the probability of exploitation in the wild, is 0.0003. That EPSS number will almost certainly rise now that the CVE is public and the exploitation pattern is documented.
The fix adds another trust flag
The patch, commit 9599bfb, touches six files with 153 lines added and 31 deleted. It introduces a whitelist: attention kernels from the kernels-community repository are trusted by default. Kernels from any other source require a new keyword argument: allow_all_kernels=True. The commit documentation draws a direct parallel to the existing trust_remote_code=True flag.
This is not a security architecture. This is a second door with the same lock. The trust_remote_code flag was supposed to be the boundary between safe model loading and code execution. CVE-2026-4372 proved that boundary was porous. The response is to carve out a second namespace, give it its own flag, and declare it safe. The underlying mechanism—downloading and executing code based on a string in a JSON file—remains intact.
The real failure is upstream
The consensus response treats this as a Hugging Face security failure. That diagnosis is too narrow. The Transformers library is the highest-value target, but the root cause sits one layer down in the stack. PyTorch's torch.load uses Python's pickle by default. Pickle is not a serialization format. It is a bytecode interpreter. Loading a pickle file means executing arbitrary code. Safe deserialization of untrusted pickle data is mathematically impossible without a sandbox, and the Python ecosystem has known this for two decades. Hugging Face is the canary in the coal mine. The gas is pickle.
Every model weight file in the PyTorch ecosystem is a potential code execution payload. The industry has papered over this with naming conventions, trust flags, and the hope that nobody would look too closely. CVE-2026-4372 is what happens when someone looks.
What happens next
Here is what the confirmed facts mean for the trajectory of the AI supply chain.
Within 24 months, running pip install transformers and loading a community model will carry the same operational risk profile as downloading a random executable from a forum in 2004. The security community will treat it that way. Enterprise procurement and compliance teams will treat it that way. The current architecture, where model weights and executable code share the same deserialization path and the same trust boundary, is proving to be terminal.
Hugging Face will be forced to decouple model weights from executable code entirely. The Transformers library as it exists today—a monolithic package that handles both model architecture definitions and weight loading—will fragment. A secure runtime will handle inference. An untrusted content ecosystem will distribute weights. The two will communicate through a defined, auditable interface, not through pickle files masquerading as data.
A new open-source standard for sandboxed model execution will emerge. The backing will likely come from AWS or Google, because the cloud providers have the strongest incentive to sell isolated inference endpoints as the secure alternative. The winners are the hyperscalers who can offer "trusted execution environment" as a premium feature. The losers are local-first practitioners who will face a thicket of security warnings, mandatory sandboxing, and restricted APIs that make the current trust_remote_code friction look like a golden age of convenience.
What operators need to do now
Audit every environment that runs Transformers. Versions 4.56.0 through 5.2.x are vulnerable. Patch to 5.3.0 immediately. Do not assume your exposure is low because you set trust_remote_code=false. That flag did not protect you. The exploit path runs through a configuration field that the library treats as internal, and the attack requires no user interaction beyond loading a model.
The download numbers are not comforting. CSO Online reports that vulnerable versions still account for roughly a quarter of weekly installs, 7 to 8 million downloads per week. That is not a patching lag. That is a population of systems that will remain exposed until their operators discover that the safety switch they relied on was bypassed nine months ago.
If your workflow loads models from any source you did not personally audit, including models fine-tuned from trusted base checkpoints, you are running untrusted code. Start planning the migration to a sandboxed inference architecture now. The current model is broken. The next vulnerability will not require a trust_remote_code bypass because there is no trust boundary left to bypass.
The 25 percent figure is not a statistic about patching behavior. It is a measure of how many practitioners still believe the safety switch works. It does not. The silent patch was the final warning.
