A Configuration File Is Not Supposed to Run Anything
A developer at a European manufacturer pulls a model from a public hub, calls from_pretrained, and goes to lunch. The library fetches the weights, reads the JSON file that describes them, and initialises. Nothing in that sequence looks like consent to execute a stranger's code, and the developer has already set trust_remote_code to False so that it is not.
Security researchers at Pluto Security demonstrated that it was. The flaw is tracked as CVE-2026-4372, carries a CVSS base score of 7.8, and is classified under CWE-502, deserialization of untrusted data. It converts a routine model pull into arbitrary Python execution on the machine doing the pulling, and the user action required is nothing more than the documented way to load a model.
How a Metadata Field Walked Past the Flag
The flag guards code files. The attack arrived in metadata. The configuration constructor contained a loop that took every key and value from the untrusted JSON and wrote them onto the config object directly, with no allowlist and no validation. Among the fields an attacker could therefore set was one called _attn_implementation_internal, a private internal attribute nobody expected to be reachable from a downloaded file.
When that field held a string shaped like owner and repository, the kernel loader treated it as a package to fetch from the hub and imported it with no safety checks. Any Python placed in that repository's initialisation file then ran. The consent gate that developers rely on was never consulted, because it was scoped to custom modelling code and this was not custom modelling code. It was a settings file.
The Patch Arrived First. The Warning Took Another 81 Days
The dates are the story. The vulnerable code entered the library on 29 August 2025 and shipped in every release for roughly six months. The flaw was reported through a bug bounty on 23 February 2026, a maintainer opened the fix on 2 March, and version 5.3.0 closed it on 4 March. That is a fast and creditable response, ten days from report to patched release.
Then the public record went quiet. CVE-2026-4372 was not published until 24 May 2026, 81 days after the fix was already sitting in a public release. In that gap the patch was described in release notes as a kernels security issue, with no CVE number, no severity and no mention that it stopped remote code execution. Any operator whose patching is triggered by CVE feeds and vendor advisories, which is most regulated operators in Europe, had no signal to prioritise an upgrade that was already available.
Then the Hub Itself Was Breached Through the Same Class of Door
On 16 July 2026 Hugging Face disclosed an intrusion into part of its own production infrastructure. A malicious dataset abused two code-execution paths in dataset processing, a remote-code dataset loader and a template injection in a dataset configuration, to run on a processing worker. From there the intruder escalated to node access, harvested cloud and cluster credentials, and moved laterally into several internal clusters across a weekend. Forensics reviewed more than 17,000 recorded actions.
Hugging Face states it found no evidence of tampering with public models, datasets or Spaces, and verified its software supply chain clean. Treat the incident as proof of the escalation path rather than as a reason to distrust the hub. A file that describes data reached a worker, and the worker held credentials. That is the shape of the risk, and it is the same shape as the configuration flaw above.
What to Settle Before Your Next Model Pull
Three checks, in order. Confirm which version of transformers runs in your training images, your notebooks and your build agents, and upgrade anything below 5.3.0. Establish whether the kernels package is installed alongside it, since that is what made the path exploitable. Then look at what credentials sit on the machines that parse model and dataset artefacts, because those machines are usually treated as data plumbing and given broad access accordingly.
The reporting duty runs on its own clock regardless. Under Article 23 of NIS2 an in-scope entity owes its national authority an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month. In the United Kingdom the equivalent guidance comes from the NCSC. None of those deadlines pause while you work out which library version you were running.
Read next: One Request Could Hijack Your WordPress Site | Patching SharePoint No Longer Closes the Door



