Silent RCE in Hugging Face Transformers Hides Behind a Single Config Field

Key points

• CVE-2026-4372 allows arbitrary code execution on any machine that loads a poisoned Hugging Face model, bypassing the trust_remote_code=false flag entirely.
• The exploit requires only a single show-prefixed field in a model's config.json file.
• Vulnerable versions (4.56.0 through 5.2.x) are still downloaded 7 to 8 million times per week, accounting for roughly a quarter of weekly installs.
• The optional kernels package must be present to trigger execution, but GPU-accelerated inference users, the most valuable targets, almost universally have it.
• Upgrade to Transformers 5.3.0 and audit cached config.json files for any instance of _attn_implementation_internal.

The vulnerability is elegant in the worst possible way. A single show-prefixed key in a model's config.json file triggers arbitrary code execution on the loading machine, bypassing trust_remote_code=false, the flag developers reasonably assumed was load-bearing.

Pluto Security published the details. CVE-2026-4372 affects all Hugging Face Transformers versions from 4.56.0 onward, every release since August, and was quietly fixed in 5.3.0, shipped March 3. Vulnerable versions still account for roughly a quarter of weekly installs, pulling 7 to 8 million downloads per week.

How three separate decisions combine into one silent exploit

The attack chains three independent design decisions. The config parser uses Python's setattr to load every key-value pair from config.json into the config object without distinguishing user-configurable fields from show-prefixed internal ones. The internal attribute _attn_implementation_internal, which normally governs whether the model uses Flash Attention or SDPA, is never validated against an allowlist. Then hub_kernels.py reads that attribute and, if its value matches an owner/repo pattern, fetches and executes the named kernel repository from the Hub. No sandboxing, no signature check, no prompt.

Publish a model. Set _attn_implementation_internal to attacker/malicious-kernel. Wait. That's the full exploit.

The one limiting factor is the optional kernels package, which must be present on the victim's machine. That sounds restrictive until you remember the affected population: GPU-accelerated inference users, ML engineers, enterprise ML platforms, CI/CD pipelines, almost universally install Transformers with all extras for peak hardware utilisation. The people most exposed are the most valuable targets.

This isn't a credential problem. It's a deserialization problem dressed in AI-framework clothing, and the attack surface is the model loading call itself: AutoModelForCausalLM.from_pretrained("model-name"). We covered a structurally similar deserialization flaw in May, when SharePoint's config parsing handed attackers full server access with no extra authentication required.

Should you worry about the broader supply-chain picture?

The broader context is grim. Malicious models appear on the Hugging Face platform regularly. A fake OpenAI model hit the number-one trending spot within 18 hours last month and was downloaded 244,000 times before removal. Researchers have separately shown RCE paths through Pickle files, through tokenizer.json manipulation, and, disclosed last month, through ChromaDB configurations that pull attacker-controlled code from the Hub.

Pluto Security's guidance is direct: treat every ML model-loading API as a code execution surface regardless of whatever safety flags the library exposes. Sandbox model loading in isolated containers and restrict outbound network access from those containers.

Transformers users should upgrade to 5.3.0 now. Search cached config.json files for any instance of _attn_implementation_internal; its presence there is not normal.