Listen to this Post
A New Warning for the AI Supply Chain
Artificial intelligence has created a new kind of software supply chain, one where developers do not simply download libraries and install packages. They also download models, configurations, pipelines, components, datasets, and other artifacts from enormous public repositories. That convenience has transformed platforms such as Hugging Face into essential infrastructure for modern AI development—but it has also created a dangerous new attack surface.
Three high-severity vulnerabilities in Hugging Face’s Diffusers library demonstrate exactly how that risk can materialize. Collectively referred to as FaceHugger, the flaws can allow malicious model repositories to bypass the library’s trust_remote_code protection and ultimately execute arbitrary Python code on a victim machine.
The vulnerabilities affect versions of Diffusers before 0.38.0, with the fixes incorporated into version 0.38.0 released on May 1, 2026. Current Diffusers releases have moved beyond that patched version, with the project listing version 0.39.0 as a July 2026 release.
For organizations building AI systems, this is more than another Python vulnerability. It is a warning that an AI model repository should not automatically be treated as a passive storage location. A model package can contain configuration files, Python modules and loading instructions that influence what happens on the machine when the model is opened.
The Problem Behind FaceHugger
Researchers Gal Zaban and Ido Shani of Zafran Labs described the core problem as a failure in the security boundary surrounding trust_remote_code.
The option exists for an important reason: remote Python code is dangerous. When users load a model from a Hugging Face repository, Diffusers can encounter custom pipeline or component code. The security mechanism is intended to prevent that code from executing unless the user explicitly trusts it.
The vulnerabilities demonstrated that this protection could be bypassed.
The deeper issue was architectural. The security decision could be made during one stage of the loading process, while the actual code could be obtained or loaded during a later stage. In security engineering, that gap is associated with a Time-of-Check to Time-of-Use, or TOCTOU, condition.
In other words, the system checked one version of what it was about to load and later used something that could differ from what had been checked.
Why trust_remote_code Matters
The name of the security control is almost self-explanatory.
When trust_remote_code is disabled, Diffusers is supposed to prevent untrusted Python code from a remote model repository from being executed. That creates a meaningful barrier between downloading a model and running arbitrary software.
The problem with FaceHugger was not simply that remote code existed.
The more serious problem was that certain loading paths could make the security mechanism believe that no dangerous code was present, while a later part of the process could still locate and execute custom Python code.
That distinction is crucial.
A security control is only effective if it remains attached to the operation it is supposed to protect. If the check occurs too early, or only covers one source while another source is subsequently loaded, an attacker can potentially move malicious behavior into the gap.
CVE-2026-44827: The Dangerous None.py Path
One of the most striking vulnerabilities is CVE-2026-44827, which received a CVSS score of 8.8.
According to the NVD record, versions before 0.38.0 could allow remote code execution through a specially crafted repository containing a file named None.py. The problem occurred because the downstream loading logic could transform a missing custom_pipeline value into the literal filename None.py, while the earlier security check did not treat the situation as remote custom code.
That creates an unsettling scenario.
A developer could invoke the normal DiffusionPipeline.from_pretrained() workflow without intentionally enabling remote code execution, yet a malicious repository could contain the specially named Python file and manipulate the loading process into executing it.
This is precisely the kind of vulnerability that makes supply-chain security so difficult: the dangerous action does not necessarily look dangerous to the person performing it.
CVE-2026-45804: The TOCTOU Race
The second vulnerability, CVE-2026-45804, carries a CVSS score of 7.5 and is directly associated with the TOCTOU problem.
Security databases describe the flaw as allowing a repository’s contents to change between the security validation phase and the later loading phase. Diffusers could make separate requests when obtaining information from the Hub, creating a window in which the content subsequently used by the loader was not necessarily identical to the content that had passed the earlier check.
This is a classic security lesson applied to a very modern AI environment.
If a program says, “I checked this file and it was safe,” but later loads a different state of that resource, the original security decision no longer guarantees anything.
The problem becomes particularly concerning when the resource is code.
CVE-2026-44513: Another Trust Boundary Failure
The third vulnerability is CVE-2026-44513, also rated 8.8.
The NVD describes several variants involving custom pipelines and local snapshots. In affected versions, the trust_remote_code enforcement was positioned around the download process rather than directly at the point where dynamic modules were loaded. Certain paths could therefore bypass the intended security gate and reach custom Python code anyway.
One important example involves using a trusted primary repository together with a separate custom pipeline source. The security decision could be associated with the wrong repository, allowing code from the other source to be loaded.
Another path involved local snapshots containing unexpected Python components.
This demonstrates that the problem was broader than one strange filename or one race condition. The underlying architectural weakness could manifest through multiple loading paths.
Why AI Model Repositories Are Different
Traditional software supply-chain attacks have generally focused on packages, dependencies, build scripts and compromised source repositories.
AI introduces another layer.
A model repository can contain weights, configuration files, tokenizers, metadata, pipeline definitions, custom components and executable code. Developers often interact with these resources through high-level APIs that make the entire process appear almost effortless.
That abstraction is useful for productivity.
It can also hide the moment when “download a model” becomes “execute software.”
Hugging Face Is Becoming Critical AI Infrastructure
Hugging Face occupies a unique position in the AI ecosystem.
Developers use it to discover models, download pretrained systems, build experimental applications and integrate AI components into production environments. Diffusers itself is designed around state-of-the-art diffusion models for image, video and audio generation.
The scale matters because a vulnerability in a widely used AI library does not remain confined to a handful of researchers.
A vulnerable dependency can appear inside notebooks, Docker images, CI/CD pipelines, internal model-serving infrastructure, development environments and production applications.
That turns a seemingly narrow library vulnerability into a potential supply-chain issue.
The Real Risk Is Not the Model File Alone
It is tempting to think of an AI model as a large collection of numerical weights.
That mental model is incomplete.
Modern AI repositories can behave more like software packages than passive datasets. Configuration determines which classes are instantiated. Loading logic determines which files are fetched. Custom components can contain executable Python. Auxiliary files can influence how an application behaves.
That means security teams need to ask a different question.
Not simply, “Where did this model come from?”
But also, “What exactly happens on the machine when this model is loaded?”
A Malicious Repository Could Become the Initial Access Point
The most concerning scenario is deceptively simple.
An attacker publishes a repository designed to look legitimate. The repository may contain an attractive model, familiar configuration structure or a convincing description.
A developer downloads it.
The application calls from_pretrained().
The developer believes remote code execution has been disabled.
A vulnerable loading path defeats that assumption.
At that point, arbitrary code execution can potentially occur within the privileges of the process loading the model.
The
Why Containers Do Not Automatically Solve the Problem
Containers are valuable security boundaries, but they are not magic shields.
If a malicious model executes code inside a container, the attacker receives whatever permissions, credentials, mounted directories and network access that container has.
A container with broad cloud credentials can be dangerous.
A container with access to private model repositories can be dangerous.
A container connected to internal databases or orchestration systems can be dangerous.
The security question therefore becomes one of blast radius.
If model loading must execute code, the environment performing that operation should have as little authority as possible.
The CI/CD Problem Is Especially Serious
AI development increasingly happens through automated pipelines.
A workflow may download a model, validate it, convert it, optimize it, package it and deploy it without a human inspecting every repository.
That creates an attractive environment for supply-chain attackers.
If a vulnerable library is installed in the runner and an untrusted model is processed automatically, the attacker may not need to compromise the application’s main source repository.
The model itself can become the delivery mechanism.
Developer Machines Are Also Valuable Targets
Not every attack needs a production server.
Developer machines frequently contain SSH keys, cloud credentials, package registry tokens, Git credentials, source code and access to private repositories.
A malicious model that executes code in a developer environment could potentially turn a single model-loading operation into a much larger compromise.
This is why local AI experimentation deserves the same security discipline traditionally applied to software development tools.
The “Safe by Default” Illusion
The FaceHugger vulnerabilities also raise an uncomfortable design lesson.
Developers often assume that a parameter named trust_remote_code=False provides a strong guarantee.
That assumption is reasonable.
If the security mechanism can be bypassed through an alternate code path, however, the interface creates a false sense of safety.
Security controls must be enforced at the final dangerous operation, not merely during an earlier preparation stage.
Patch First: Diffusers 0.38.0
The most important remediation is straightforward: upgrade Diffusers to 0.38.0 or later.
The project released version 0.38.0 on May 1, 2026, and vulnerability records identify that version as the fixed release. The project has since published newer versions, including 0.39.0 in July.
Organizations should not interpret “0.38.0 or later” as permission to remain permanently pinned to the first patched release.
Where practical, use a currently supported release compatible with the organization’s application and test it before production deployment.
Check Installed Versions
Teams can quickly determine which Diffusers version is installed with a standard Python package query:
python -m pip show diffusers
A more compact check is:
python -c "import diffusers; print(diffusers.<strong>version</strong>)"
For dependency inventories, teams should also search lockfiles and container definitions rather than relying only on the currently active Python environment.
Search Dependency Files
Security teams can search common dependency files for Diffusers:
grep -Rni "diffusers" requirements.txt requirements.txt pyproject.toml poetry.lock uv.lock 2>/dev/null
For larger repositories, dependency scanners should be preferred over simple text searches because transitive dependencies can be missed by manual inspection.
Upgrade the Package
For a direct Python installation, the basic remediation is:
python -m pip install --upgrade "diffusers>=0.38.0"
Production environments should pin and review the resulting dependency version rather than blindly allowing uncontrolled upgrades.
A safer operational process is to update the lockfile, run automated tests, inspect dependency changes and then promote the new build through staging.
Audit Model Loading Code
Search application code for from_pretrained usage:
grep -Rni "from_pretrained" . --exclude-dir=.git
The goal is not simply to find vulnerable code.
Teams should identify every location where external or semi-trusted repositories can enter the system.
Then ask whether those repositories are explicitly allowlisted, whether their contents are reviewed, and whether model loading occurs in a sandbox.
Inspect Custom Pipelines
Search for custom pipeline usage:
grep -Rni "custom_pipeline" . --exclude-dir=.git
Any workflow that uses custom pipeline functionality deserves additional scrutiny because the vulnerabilities specifically involve custom loading paths.
Do not assume that disabling trust_remote_code alone provides complete protection on an unpatched version.
Inspect Local Model Snapshots
For locally cached or downloaded model directories, inspect unexpected Python files:
find /path/to/model -type f ( -name ".py" -o -name "model_index.json" ) -print
Unexpected Python modules under directories such as unet/, scheduler/, or the model root deserve particular attention.
The presence of a Python file does not automatically mean the repository is malicious, but it means the file should be understood before the model is trusted.
Restrict Model Sources
Organizations should establish an allowlist for approved model repositories rather than allowing production systems to pull arbitrary models from the internet.
A trusted model registry can become an important control point.
The ideal architecture is not “every server can download any model.”
It is “approved models are scanned, verified, stored internally and then consumed by controlled workloads.”
Treat Model Artifacts as Executable Supply-Chain Inputs
This is perhaps the most important conceptual change.
A model should be treated closer to a software dependency than to an ordinary image or document.
That means model provenance, integrity, versioning and ownership should become part of the security process.
Organizations already ask these questions about npm packages and Python libraries.
They should increasingly ask the same questions about AI models.
What Undercode Say:
The AI Supply Chain Has Expanded
The biggest lesson from FaceHugger is that the AI supply chain is significantly larger than traditional package management.
A company can secure its Python dependencies and still have an untrusted model entering its infrastructure.
Model Downloads Are Becoming Code Paths
A model download may look like a data operation, but the loading framework can interpret configuration and dynamically load modules.
That makes model ingestion a potential execution boundary.
Security Flags Need Strong Guarantees
A security parameter should not merely express developer intent.
If trust_remote_code=False is expected to prevent remote code execution, the enforcement mechanism must remain effective regardless of which internal loading path is used.
TOCTOU Bugs Are Especially Dangerous Here
TOCTOU vulnerabilities are dangerous because they exploit inconsistencies between what a system verifies and what it later consumes.
In an AI repository, that gap can become a bridge from metadata validation to arbitrary code execution.
The Repository Is Part of the Attack Surface
Security teams should stop thinking exclusively about the model weights.
The repository structure itself can influence execution.
Configuration files, custom pipeline modules and component definitions can all matter.
CI/CD Systems Need Model Controls
Automated systems should never blindly ingest arbitrary AI repositories.
A compromised model-loading job can expose credentials and build infrastructure even when the application’s source code remains untouched.
Container Isolation Should Be Aggressive
AI model processing should run with minimal privileges.
Where possible, workloads should use isolated identities, restricted network access, read-only resources and short-lived credentials.
Production Model Loading Should Be Deterministic
A production workload should ideally load a known model version rather than dynamically resolving an uncontrolled repository state.
Pinning versions reduces uncertainty and makes forensic investigation easier.
Model Provenance Matters
Teams should record where a model came from, which revision was approved, when it was scanned and which application consumed it.
Without provenance, incident responders may struggle to reconstruct what entered an environment.
AI Security Needs Software Supply-Chain Thinking
Traditional software security already understands dependency confusion, malicious packages and compromised repositories.
AI infrastructure needs to inherit those lessons rather than reinvent them.
Trust Must Be Explicit
A model should not become trusted simply because it is popular.
Popularity is not cryptographic verification.
A heavily downloaded repository can still contain vulnerabilities or malicious content.
High Download Numbers Increase the Stakes
Diffusers is widely used, and the
That does not mean every installation is vulnerable today.
It does mean that flaws in a common AI dependency deserve serious attention because the downstream ecosystem can be large.
Developers Should Inspect Before They Execute
If a model requires custom Python code, developers should understand what that code does before allowing it to execute.
The difference between “downloaded” and “trusted” should remain explicit.
Local Snapshots Deserve Equal Attention
The danger is not limited to remote repositories.
Local model snapshots can also contain executable components.
A file being stored locally does not make it trustworthy.
AI Security Cannot Depend on One Boolean
A single configuration option cannot compensate for an insecure architecture.
Defense needs multiple layers: patching, provenance, sandboxing, network controls, identity restrictions and monitoring.
Model Registries Should Become Security Gateways
Enterprises can reduce risk by placing approved models behind internal registries.
Instead of every workload reaching the public internet, models can be scanned and approved centrally.
Vulnerability Management Must Include AI Artifacts
Traditional vulnerability scanners need to expand beyond operating systems and packages.
AI-specific components, model loaders and model repositories should appear in software inventories.
The Attack Surface Is Moving Up the Stack
AI attacks are increasingly targeting the infrastructure surrounding models rather than the mathematical model itself.
That trend will likely continue as AI becomes embedded into business systems.
Model Loading Is an Underestimated Security Event
Organizations commonly monitor logins, software installations and network connections.
They should also consider model loading events worthy of security telemetry.
Unusual Python Files Should Trigger Review
Unexpected .py files inside model repositories should not automatically be classified as malicious.
But they should trigger examination when the application was not supposed to execute custom code.
Security Teams Need AI-Aware Incident Response
When a suspicious model is loaded, investigators should examine process execution, outbound network connections, credentials accessed and files modified.
The investigation should not stop at the model repository.
Secrets Are the Real Prize
An attacker who achieves code execution on an AI worker may not care about the worker itself.
Cloud credentials, API tokens and internal service credentials can provide much greater value.
Least Privilege Becomes Critical
The less authority a model-processing environment has, the less damage an attacker can cause after successful exploitation.
Network Segmentation Can Break Attack Chains
An isolated model worker should not have unrestricted access to production databases or internal management services.
Segmentation can turn an RCE vulnerability into a contained incident rather than an enterprise-wide compromise.
Reproducible Builds Improve Security
Pinned dependencies and reproducible containers make it easier to know exactly what code was running when a model was processed.
That dramatically improves both prevention and investigation.
AI Governance and Cybersecurity Are Converging
Model governance is no longer only about accuracy, bias or compliance.
It increasingly includes provenance, integrity, executable content and supply-chain risk.
The Hugging Face Ecosystem Needs Layered Trust
Public repositories provide enormous value.
But public availability should never be confused with security approval.
Security Reviews Should Follow Data Into Execution
Whenever a model moves from storage into a Python process, the security posture changes.
That transition should be treated as an execution boundary.
FaceHugger Is a Warning, Not an Isolated Curiosity
The three vulnerabilities should not be dismissed as obscure implementation mistakes.
They reveal a broader architectural challenge that could appear in other AI libraries with similar dynamic loading behavior.
Developers Need Better Visibility
High-level APIs are convenient, but they can conceal dangerous operations.
Security-sensitive frameworks should make it obvious when custom code is about to be executed.
Silent Execution Is the Worst User Experience
A developer who explicitly chooses to execute remote code can at least understand the risk.
A developer who believes remote code is blocked but unknowingly triggers it faces a much more dangerous situation.
AI Supply Chains Will Become More Attractive to Attackers
As organizations increasingly depend on open-source models and AI tooling, attackers have strong incentives to search for weaknesses in model loading, dependency resolution and repository infrastructure.
The Best Defense Is to Reduce Trust
Do not ask whether every model is safe.
Design systems so that even a malicious model has very little authority.
Patch Management Must Move Faster
When a high-severity AI library vulnerability is disclosed, organizations should identify affected workloads immediately.
Waiting for a broader maintenance cycle can leave model-processing infrastructure unnecessarily exposed.
Security Architecture Must Assume Failure
The strongest AI systems are designed around the assumption that a model may eventually be malicious or compromised.
That mindset produces better isolation, better monitoring and smaller blast radii.
The AI Era Needs a New Supply-Chain Standard
The industry is still developing the equivalent of mature software supply-chain practices for models.
FaceHugger is another signal that this cannot remain an afterthought.
Deep Analysis: The Command Path From Model Download to RCE
from_pretrained() Is the Critical Entry Point
The central operation in these vulnerabilities is the Diffusers DiffusionPipeline.from_pretrained() workflow.
It is designed to make model loading easy, but that convenience means a single API call can trigger a surprisingly complex sequence of repository discovery, configuration processing, downloading and dynamic module loading.
trust_remote_code=False Is Not the Whole Security Model
The vulnerable versions demonstrate why developers cannot treat a Boolean security option as a complete security architecture.
The check has to protect the actual dynamic execution point.
Otherwise, another internal path can potentially bypass it.
The TOCTOU Pattern Explains the Race
The vulnerable workflow could perform validation and retrieval as separate operations.
Conceptually, the dangerous sequence looks like this:
CHECK repository state
↓
repository state changes
↓
USE repository contents
↓
unexpected code executes
The fix therefore has to ensure that the security decision remains valid for the resource actually consumed.
Custom Pipelines Increase Complexity
Custom pipelines are powerful because they allow developers to extend the normal model-loading architecture.
But every extension point increases the number of paths that security controls must cover.
This is why custom loading functionality deserves additional scrutiny.
Local Paths Can Be Security Boundaries Too
CVE-2026-44513 demonstrates an important principle: local does not automatically mean safe.
If a local snapshot contains executable Python components, loading it can still create a code-execution path.
Security teams should therefore distinguish between local and trusted.
They are not synonyms.
Repository Isolation Should Be Standard
A mature AI platform should isolate model acquisition from sensitive workloads.
A model can first enter a restricted scanning environment, where its files and metadata are inspected.
Only after approval should the artifact be promoted to an environment where it can interact with production services.
Credentials Should Never Be Available to Model Workers by Default
A model-loading process should not have unnecessary cloud credentials.
If the worker becomes compromised, those credentials become immediately available to the attacker.
Short-lived credentials and narrowly scoped identities can significantly reduce the impact.
Outbound Network Access Should Be Restricted
An attacker who gains code execution may attempt to establish external communication.
Restricting outbound traffic can make command-and-control and data exfiltration substantially harder.
Runtime Monitoring Adds Another Layer
Security teams should monitor model-processing environments for unusual child processes, unexpected network connections, shell execution, credential access and modifications outside expected directories.
A model loader should behave predictably.
Deviation can become a useful detection signal.
The Strategic Lesson Is Bigger Than Diffusers
The FaceHugger vulnerabilities expose a category of risk that extends beyond one library.
Any AI framework that downloads artifacts and dynamically interprets code can potentially create similar challenges.
The industry should therefore examine the architecture of model loaders as a class, not merely patch individual CVEs.
✅ The vulnerabilities are real
Multiple vulnerability databases and the NVD confirm high-severity Diffusers vulnerabilities involving trust_remote_code bypasses and remote code execution. CVE-2026-44827 and CVE-2026-44513 are documented as affecting Diffusers versions before 0.38.0.
✅ Diffusers 0.38.0 contains the relevant fixes
The official Diffusers release history confirms that version 0.38.0 was released on May 1, 2026, while vulnerability records identify 0.38.0 as the fixed version for the affected vulnerabilities.
✅ CVE-2026-45804 is independently documented
CVE-2026-45804 is documented as a TOCTOU trust_remote_code bypass affecting Diffusers before 0.38.0, with a CVSS score of 7.5.
Prediction
(+1) AI Model Security Will Become a Standard Enterprise Requirement
As organizations move more AI workloads into production, model provenance, artifact scanning and controlled model registries are likely to become normal enterprise security requirements.
(+1) Sandboxed Model Processing Will Expand
Organizations will increasingly isolate model downloads and model execution from sensitive production environments, limiting credentials and network access.
(+1) AI Supply-Chain Scanners Will Become More Important
Security platforms are likely to expand beyond conventional package vulnerability scanning and begin inspecting model repositories, configuration files and executable components.
(-1) Attackers Will Target Model Repositories More Aggressively
The growing dependence on public AI repositories creates an attractive target for attackers seeking a single weakness that can spread across many downstream applications.
(-1) Developers May Continue Trusting High-Level APIs Too Much
The convenience of APIs such as from_pretrained() can hide complicated security behavior. Without better security education and framework-level protections, developers may continue assuming that a disabled security flag guarantees complete protection.
(+1) The Industry Will Move Toward Zero-Trust AI Artifacts
The most resilient architecture will increasingly treat every external model as potentially hostile until its provenance, contents and behavior have been validated.
Final Assessment: AI Models Are Software Supply-Chain Components
The most important lesson from FaceHugger is simple but profound: an AI model is not necessarily just data.
Modern model repositories can contain executable code, configuration and loading instructions capable of influencing the behavior of the software consuming them.
The vulnerabilities in Diffusers show how a seemingly protective control such as trust_remote_code can fail when validation and execution are separated across complicated loading paths.
For developers, the immediate response is to update Diffusers and audit model-loading workflows.
For security teams, the bigger task is architectural: isolate model processing, restrict privileges, control model provenance, monitor execution and assume that anything downloaded from the public AI ecosystem may eventually become an attack vector.
The AI revolution is rapidly turning model repositories into critical infrastructure. Security must evolve just as quickly—or the same convenience that makes AI development incredibly fast could become the mechanism that gives attackers their fastest route inside.
▶️ Related Video (76% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: thehackernews.com
Extra Source Hub (Possible Sources for article):
https://stackoverflow.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
