Key Takeaways
Zafran Labs disclosed three vulnerabilities in Hugging Face's Diffusers library, CVE-2026-44827, CVE-2026-45804, and CVE-2026-44513, collectively called FaceHugger.
Two of the three flaws let a malicious model repository execute code even when developers explicitly set trust_remote_code=False, the parameter meant to block exactly this.
The root cause is a time-of-check to time-of-use race condition between two sequential HTTP calls to the Hugging Face Hub, not a cryptographic or authentication failure.
The flaws were fixed in Diffusers version 0.38.0, released in May 2026, well before this week's public disclosure.
Any pipeline that pulls models automatically, including CI/CD jobs and container builds, should confirm it is pinned to Diffusers 0.38.0 or later, not just the application code.
The safeguard that was supposed to stop exactly this
Hugging Face's Diffusers library, the standard toolkit for running image and video generation models, includes a parameter called trust_remote_code that, when left at its default of False, is supposed to block a model repository from executing custom Python code on load. It is the primary control standing between "download and run a random model from the Hub" and "execute arbitrary code from a stranger." Zafran Labs researchers Gal Zaban and Ido Shani found three ways around it, disclosed publicly on August 3 under the name FaceHugger. That the safeguard has an off switch built into its own name, trust_remote_code, and still failed to hold the line is the part worth sitting with.
The most severe of the three, CVE-2026-44827 with a CVSS score of 8.8, uses a crafted pipeline file literally named "None.py" to slip past the trust_remote_code check entirely. A second flaw, CVE-2026-44513, also CVSS 8.8, achieves code injection through the library's custom_pipeline flow despite the same safeguard being active. As the researchers put it plainly, "these vulnerabilities are bypassing trust_remote_code, the safeguard designed to stop unreviewed code from running." For a control that many organizations treat as their primary defense against malicious models, that is a direct hit, and it means the parameter's name alone was never a guarantee worth relying on without testing.
A race condition, not a broken lock
The third flaw, CVE-2026-45804 at CVSS 7.5, works differently. It exploits a time-of-check to time-of-use race condition: when Diffusers loads a model, it makes what should be a single atomic verification step to the Hugging Face Hub, but the actual implementation involves two sequential HTTP calls. An attacker who can influence what happens between those two calls can swap in different code than what was verified, a classic TOCTOU bug applied to model loading instead of file system access. It is the kind of bug that tends to hide well because the two calls usually do agree, which is exactly what made it easy to miss during normal testing.
None of the three flaws breaks cryptography or requires stolen credentials. They are implementation gaps between what the safeguard was designed to guarantee and what the actual request flow enforces, the same category of problem Unit 42 flagged in this week's separate passkey research. That pattern, security controls that are conceptually sound but fail on the specific mechanics of how they check and verify, is becoming a recurring theme across AI tooling as libraries race to add safety parameters without hardening the request flows underneath them. Security teams evaluating any AI tooling vendor should ask specifically how a given safeguard has been tested against bypass attempts, not just whether the parameter exists.
Why this lands hardest in CI/CD
The realistic attack scenario is straightforward: an attacker publishes a malicious model repository to the Hugging Face Hub, and any pipeline that loads it via DiffusionPipeline.from_pretrained(), even with trust_remote_code=False explicitly set, can be tricked into executing the attacker's code. Given how embedded Hugging Face is in enterprise AI pipelines, from experimentation notebooks to automated CI/CD jobs that pull the latest version of a model on every build, the exposure is not limited to a data scientist manually downloading a suspicious file. It extends to any automated system that resolves and loads models without a human reviewing what actually got pulled.
That is the part worth flagging to engineering leadership specifically. A developer manually loading a model might notice something off; an automated pipeline pulling the "latest" tagged version of a dependency on every deploy will not. If your MLOps pipeline treats model repositories the way it treats package dependencies, resolved automatically, cached, and rebuilt without manual review, these flaws could have executed silently in a build environment with access to secrets, cloud credentials, or internal networks.
Already patched, but disclosure lag is the real risk
Hugging Face fixed all three flaws in Diffusers version 0.38.0, released in May 2026, roughly three months before this week's public disclosure. That gap is normal and responsible: researchers typically hold details until a patch ships and has time to propagate. But it also means that for three months, any organization running an older Diffusers version has been exposed without knowing there was anything to fix, and the public disclosure now gives potential attackers a clear roadmap while some fraction of the ecosystem is still unpatched.
This is the standard AI supply chain risk window: a fix exists, but adoption lags, and the library itself sits several layers beneath the applications teams are actually watching for CVEs. Most vulnerability scanning programs are tuned to flag known-vulnerable versions of application frameworks and operating system packages; far fewer are tuned to flag known-vulnerable versions of ML library dependencies buried inside a requirements.txt or a container base image built six months ago.
What to check this week
Confirm every environment that imports Diffusers, whether that is a data science notebook, a production inference service, or a CI/CD job that resolves models dynamically, is running version 0.38.0 or later. Do not assume application-level dependency scanning already caught this; explicitly search container images, requirements files, and lockfiles for the package version, since ML dependencies are frequently pinned less rigorously than core application libraries. Pull the actual installed version from a running container rather than trusting what a requirements file says it should be, since the two do not always match in practice.
Beyond the immediate patch, treat this as a prompt to inventory where your organization loads models automatically without human review, and whether trust_remote_code or equivalent safeguards in other ML frameworks are actually being tested against bypass techniques rather than just toggled on and trusted. As AI tooling becomes a standard part of the software supply chain, the libraries that load models deserve the same CVE monitoring rigor as the libraries that load code, because functionally, for an attacker, they are the same thing.
