Security researchers warn that FaceHugger flaws in Hugging Face’s Diffusers library could allow attackers to execute arbitrary code through malicious or crafted model repositories. The impact goes beyond a simple library bug: it targets how machine learning pipelines download, interpret, and run code during model loading—turning what is often treated as “data” into executable instructions.
Because Diffusers is widely used in AI development and production environments, these issues raise a practical question for teams shipping applications that load models from external sources: are your loading flows truly safe, even when you rely on safeguards such as trust_remote_code?
What are FaceHugger flaws?
The vulnerabilities have been collectively labeled FaceHugger flaws. The core idea is that crafted repositories can sneak executable Python code into the loading process for Diffusers pipelines.
According to the analysis, these problems bypass the purpose of the trust_remote_code parameter—a protection meant to stop unreviewed code from running when the loader initializes custom pipeline components via from_pretrained().
In other words: even if you attempt to restrict remote code execution, the loader can be tricked into seeing custom code in a way that the trust decision does not correctly guard against.
Why Diffusers is a high-value target
Diffusers is a Python package used for state-of-the-art diffusion models that generate images, videos, and audio. It can load models locally from repositories hosted on the Hugging Face hub by using the DiffusionPipeline API.
During this process, Diffusers relies on configuration files to initialize specific pipeline and component classes, including custom pipeline code. That means the library is not just retrieving static assets; it is also interpreting repository-provided configuration and potentially loading additional Python modules.
As Hugging Face’s ecosystem grows and organizations increasingly embed these libraries into production pipelines, continuous integration/continuous deployment (CI/CD) systems, and container images, a weakness in loading behavior can become an AI supply chain risk.
How the trust boundary fails
The researchers explain that the trust_remote_code check occurs only during the first phase of the loading flow. If an attacker can influence the loader such that it later observes custom code that was not part of what the initial trust gate evaluated, the protection can be circumvented.
In multiple variants, the root cause ties back to Time-of-Check to Time-of-Use (TOCTOU)-style behavior. Instead of treating the download and trust verification as one atomic operation, the download is described as two sequential, non-atomic HTTP requests. When configuration and code are retrieved in separate steps, there is room for timing and manipulation differences that affect what ultimately gets executed.
Vulnerability details (CVEs and severity)
Three high-severity issues were disclosed and assigned CVE identifiers. Below is what each one enables and what distinguishes it.
CVE-2026-44827 (CVSS 8.8)
This is described as a code injection vulnerability. It can allow arbitrary code to be loaded through the custom pipeline flow from a Hub repository, using a crafted pipeline that makes use of a filename pattern: None.py.
Notably, this behavior can occur even when trust_remote_code is set to False (or omitted, where it defaults to blocking unverified code execution).
CVE-2026-45804 (CVSS 7.5)
This vulnerability is characterized as a race condition. The described scenario allows an attacker to introduce arbitrary code into a repository by modifying the configuration between two HTTP download calls—specifically between hf_hub_download and snapshot_download.
The result is code execution during the model loading process.
CVE-2026-44513 (CVSS 8.8)
The third item is another code injection issue. It allows arbitrary code to be loaded via the custom pipeline flow from a Hub repository even when trust_remote_code is passed as False (or not provided).
Who is affected
After responsible disclosure, the vulnerabilities were addressed in Diffusers version 0.38.0, released in early May 2026.
Any user who invokes DiffusionPipeline.from_pretrained with custom pipelines is considered impacted. In practical terms, that includes scenarios where your application or internal tooling supports custom pipeline definitions, custom component loading, or repository-driven pipeline initialization.
Why this matters for the AI supply chain
The researchers emphasize a common misunderstanding: AI artifacts downloaded from repositories are often treated as passive data. But in these cases, configuration files, loaders, and custom pipeline code can cross the line from configuration into executable behavior.
That transforms a routine model download step into a potential initial-access vector—especially when organizations load models as part of automated workflows without strong repository auditing.
For enterprises, the risk grows when model loading is wired into production systems, CI/CD jobs, or container builds where execution might happen unattended.
What to do now: patches and workarounds
If you can patch immediately, the recommended step is to upgrade to Diffusers 0.38.0. Doing so addresses the reported weaknesses.
If immediate updating is not possible, the project maintainers suggested workarounds aimed at reducing exposure when loading from remote sources.
Use only audited trusted sources
One recommendation is to call from_pretrained only with:
- pretrained_model_name_or_path,
- custom_pipeline, and
- local snapshot directories
…coming from fully trusted sources that have been audited.
Avoid mixing Hub references for pipeline code
Do not pass custom_pipeline pointing at a Hub repository that differs from the primary pretrained_model_name_or_path before reading its pipeline.py. This helps prevent the loading flow from pulling pipeline code from unexpected locations.
Inspect local snapshots for unexpected Python files
Before calling from_pretrained on a local snapshot, inspect the snapshot content for unexpected *.py files, especially:
- inside component subdirectories such as unet/ and scheduler/, and
- at the snapshot root.
This reduces the chance that hidden or unexpected modules become part of your execution path during pipeline initialization.
Practical checklist for safer model loading
To operationalize these recommendations, consider aligning your ML pipeline processes with basic software supply chain hygiene:
- Prefer upgrades to the fixed version and keep an eye on dependency releases.
- Limit remote code pathways by treating custom pipeline functionality as high-risk.
- Audit repository contents before they enter build or runtime environments.
- Validate what gets downloaded when automation fetches model artifacts.
These steps help ensure that your model loading step stays a data retrieval task rather than an execution boundary.
Conclusion
FaceHugger flaws highlight an important reality: in modern AI stacks, model repositories can influence code execution if the loading process interprets repository content as executable components. With Diffusers, safeguards like trust_remote_code can be bypassed under certain crafted conditions, enabling arbitrary code execution.
Upgrade to Diffusers 0.38.0 where possible. If you cannot patch right away, apply the recommended trust-focused workarounds—restrict inputs to audited sources, avoid unsafe repository mixing, and inspect local snapshots for unexpected Python code.
Source: https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html
