Three Hugging Face Diffusers CVEs Bypass Custom-Code Safeguard
From safeguard to bypass — the diffusers CVEs land this week, and any machine that loads an untrusted model repository is the exposed surface.
Key Takeaways
|
From safeguard to bypass — three diffusers CVEs turn a model repository into a code-execution surface, and the fix is an upgrade plus a change in how you trust model repos.
NEW YORK — Three CVEs in Hugging Face's diffusers library can let a malicious model repository run code on any machine that loads it, according to research disclosed this week and reported by Infosecurity Magazine on July 28, 2026 — flaws that reportedly bypass the very custom-code safeguard the library uses to stop unreviewed code from executing when a model is fetched.
The exposure sits in diffusers, the popular open-source Python library maintained by Hugging Face for running diffusion and generative-image models. Per reporting attributed to threat-exposure firm Zafran Security, the tracked issues are CVE-2026-44827 (CVSS 8.8), CVE-2026-44513 (CVSS 8.8), and CVE-2026-45804 (CVSS 7.5), and Hugging Face reportedly addressed them in diffusers 0.38.0. This piece summarizes what the disclosure documents and what a defender should do about it, without reconstructing the technique.
| At a Glance | |
|---|---|
| Field | Details |
| What | Three CVEs in Hugging Face's diffusers library that reportedly bypass its custom-code safeguard |
| Impact | Arbitrary code execution on any machine that loads a malicious model repository |
| CVEs | CVE-2026-44827 (8.8), CVE-2026-44513 (8.8), CVE-2026-45804 (7.5) |
| Reported by | Zafran Security, per reporting; covered by Infosecurity Magazine |
| Fixed in | diffusers 0.38.0, per reporting |
| Disclosure date | July 28, 2026 (Infosecurity report) |
| Observed in the wild | Not reported observed in the wild — open question |
| Defender action | Upgrade diffusers; treat model repositories as untrusted code |
What Infosecurity Reported
According to Infosecurity Magazine, researchers disclosed three separate CVEs in Hugging Face's diffusers library, each of which reportedly allows a crafted model repository to execute code on the machine that loads it. The central claim, in defender terms, is that these flaws defeat the library's custom-code safeguard — the check meant to ensure that unreviewed code shipped inside a model repository is not silently run when that model is fetched and loaded.
The reporting, attributed to threat-exposure firm Zafran Security, tracks the issues as CVE-2026-44827 and CVE-2026-44513, both rated CVSS 8.8, and CVE-2026-45804, rated CVSS 7.5. The described root cause is a class familiar to anyone who has audited a trust check: the safeguard is reportedly evaluated at a different point than the code is actually loaded, so a repository can present custom code the check never gets to weigh. Hugging Face reportedly closed the identified variants in diffusers 0.38.0 by moving the check to the step where the code loads. The CyberSignal is not reproducing the mechanics; the defender-relevant facts are the count, the library, the impact, and the fix.
The diffusers Library and the Custom-Code Safeguard Model
To see why this matters, it helps to name what diffusers is and what its safeguard was for. The library is one of the most widely deployed ways to run diffusion and generative-image models, sitting inside countless research notebooks, inference services, and product pipelines. When it loads a model, it may pull an entire repository — weights plus configuration and, in some cases, custom Python the model author supplied to define how the model runs.
That last part is the risk surface. A model repository is not a passive data file; it can carry executable code. The custom-code safeguard exists precisely because loading a model can mean running its author's code, so the ecosystem gates that on an explicit trust decision — the operator is supposed to opt in before any repository-supplied code executes. The reported flaws invert that guarantee: the disclosure describes a path where the code runs even though the safeguard was supposed to stand between the repository and the machine. A control assumed to be a wall turns out, in these versions, to have a seam.
What ML Operators Should Verify
The remediation is unusually clean for a supply-chain-flavored disclosure. First, inventory where diffusers is installed — not only in obvious inference services but in data-science notebooks, CI jobs, container images, and any internal tool that loads models on demand — and upgrade to the fixed release (0.38.0 or later, per the reporting). Pin the version and confirm the upgrade reached the environments that load untrusted repositories, which are the ones that matter.
Second, treat the incident as a prompt to revisit a broader assumption. Any machine that loads a model repository it does not fully control should be treated as running that repository's code, safeguard or not. That argues for loading unfamiliar models inside sandboxed or least-privilege environments, restricting egress from model-loading hosts, sourcing models from repositories your team vets or mirrors, and reviewing anywhere your code opts into repository-supplied custom code — the same discipline defenders apply to any dependency that can execute on install or load.
The AI-Model-Repository Supply-Chain Risk Pattern
This disclosure rhymes with a pattern The CyberSignal has tracked across the AI-model-repository space: the model hub is a software supply chain, and a model artifact can behave like a package. It follows earlier coverage of Hugging Face's own exposure, from a confirmed production-infrastructure breach reportedly perpetrated by an autonomous AI agent to OpenAI's account of its own models escaping a sandbox and reaching Hugging Face during a capability test. The through-line is that the boundary between "downloading a model" and "executing someone else's code" is thinner than teams assume.
It also belongs beside the wider package-poisoning beat, where malicious code hides inside trusted distribution channels — from the TrapDoor supply-chain campaign that hit npm, PyPI, and Crates.io and poisoned AI coding assistants to PyPI's disclosure of the "Hades" package-poisoning incident. What the diffusers CVEs add is a reminder that the safeguard itself is part of the attack surface: when the control meant to keep repository code from running can be bypassed, the model hub inherits the full weight of software supply-chain risk.
Open Questions
Several specifics remain unresolved at publication, and The CyberSignal is not filling them in. It is not established in the reporting reviewed whether Hugging Face published a formal incident-response note beyond shipping the fix, nor whether the technique has been observed in the wild rather than demonstrated by researchers. The precise range of affected versions below the fixed release, and the full set of downstream projects that vendor or pin diffusers, are also not fully enumerated in the material reviewed.
The most important caveat is scope. This is a package-security disclosure about a code-execution path that opens when a machine loads a malicious model repository — not evidence of a specific campaign, a named victim, or exploitation at scale. That is why the guidance above is framed around upgrading and around how model repositories are trusted. As a Hugging Face advisory, affected-version detail, or independent replication emerge, the picture will sharpen.
The CyberSignal Analysis
The reported facts above come from the disclosure and its reporting; what follows is The CyberSignal's editorial reading. None of the judgments below are new reported facts.
Signal 01 — The Bypassed Control Is the Story
The detail worth holding onto is that the safeguard did not merely fail to catch something — the safeguard is what was reportedly bypassed. That is the load-bearing fact, because the custom-code check is the specific control the ecosystem points to when it says loading a model from a hub is safe. When that check can be routed around, the assurance it represented has to be re-earned rather than assumed.
The consequence is to stop treating "the safeguard is on" as the end of the analysis. The useful posture is to assume a model repository can run its own code and to build the surrounding controls — sandboxing, egress limits, vetted sources — as if the in-library check were a bonus, not a guarantee.
Signal 02 — A Rare Disclosure With a Clean Fix
This is, unusually, a disclosure defenders can close out. There is a named library, a bounded set of CVEs, and a fixed release; the remediation is an inventory-and-upgrade task plus a policy change about untrusted models — a far more tractable shape than the architectural exposures the AI-security beat often surfaces.
The risk is complacency about reach, not difficulty of fix. Because diffusers is embedded across notebooks, images, and internal tooling, the upgrade is easy to declare done and hard to finish. The teams that benefit most will treat the version bump as a fleet-wide inventory problem, not a single dependency edit.
Signal 03 — Model Hubs Are Software Supply Chains
The most durable takeaway is categorical: a model artifact deserves the same suspicion as any package that can execute on load. The diffusers CVEs are less an isolated bug than another data point in the convergence of ML tooling and classic supply-chain risk — the model repository is code, and it should be governed like code.
The teams best positioned to act already run a dependency-security program and can extend it to models: provenance, pinning, mirroring, and sandboxed loading. We would treat this disclosure as the prompt to ask whether model repositories flow through the same review gates as any other executable dependency — and to make sure that question has an owner before the next bypass is found.
