>samit_hota
Back to security news
SN-2026-278HighResolved

Hugging Face Diffusers Flaws Bypass Remote Code Safeguards

Samit Hota·
CVE ID
CVE-2026-44827, CVE-2026-45804, CVE-2026-44513
Affected Products / Orgs
Hugging Face Diffusers (versions prior to 0.38.0)
#news#vulnerability-disclosure#hugging

Loading a pretrained model from a public repository should not give an attacker a shell on your inference server, but three high-severity security flaws in the Hugging Face Diffusers library did exactly that. Tracked as CVE-2026-44827, CVE-2026-45804, and CVE-2026-44513, these vulnerabilities allow malicious model repositories hosted on the Hugging Face Hub to quietly achieve arbitrary code execution during routine model loading operations—even when developers explicitly tell the library not to run remote code.

Discovered by Zafran Labs researchers Gal Zaban and Ido Shani, the flaws bypass trust_remote_code, the primary security flag built into Hugging Face libraries to block unreviewed Python scripts from executing during DiffusionPipeline.from_pretrained() calls. The vulnerabilities affect any environment that loads custom pipelines using the Diffusers Python package prior to version 0.38.0.

Anatomy of the Trust Bypass

The standard workflow for loading a diffusion model involves fetching configuration files, model weights, and pipeline definitions from either a remote Hugging Face Hub repository or a local snapshot directory. To protect users from malicious models containing executable Python code, Hugging Face implements the trust_remote_code parameter. Setting this parameter to True allows custom Python code embedded in the repository to run, while setting it to False (or leaving it at its default omitted state) is supposed to enforce a strict block on unverified code execution.

However, all three vulnerabilities exploit a fundamental structural flaw: the trust check and the actual code loading process are split across two sequential, non-atomic steps. Because the security gate checks for untrusted code during the initial phase rather than during the final execution phase, attackers can introduce executable code that the security check never evaluated—a classic Time-of-Check to Time-of-Use (TOCTOU) condition.

The three specific vulnerabilities operate through distinct mechanisms:

  • CVE-2026-44827 (CVSS 8.8): A code injection vulnerability within the custom_pipeline flow. An attacker constructs a repository containing a crafted pipeline named None.py. During the initialization phase, the loader’s security check misses the payload, but the execution logic subsequently loads and executes the custom code, ignoring trust_remote_code=False.
  • CVE-2026-45804 (CVSS 7.5): A race condition vulnerability that exploits non-atomic HTTP calls made during model ingestion. The loader makes separate hf_hub_download and snapshot_download HTTP calls to fetch repository metadata and files. By manipulating the repository configuration in the window between these two network requests, an attacker can substitute remote code after the trust_remote_code check has already passed, leading to arbitrary code execution.
  • CVE-2026-44513 (CVSS 8.8): Another high-severity code injection flaw in the custom_pipeline handling mechanism. Similar to CVE-2026-44827, it permits arbitrary Python code to be pulled from a Hub repository and executed locally even when users pass trust_remote_code=False or omit the flag entirely.

AI Supply Chains and the “Passive Data” Fallacy

These vulnerabilities highlight a dangerous assumption prevalent across modern machine learning engineering: the belief that AI model artifacts are passive data structures like images or text files. In reality, modern ML frameworks rely heavily on dynamic Python loading, custom pipeline logic, and complex configuration parsing to assemble neural network architectures at runtime.

Because Hugging Face has effectively become the central software registry for open-source AI, its client libraries—including Diffusers, Transformers, and Datasets—are baked directly into enterprise production pipelines, automated CI/CD evaluation workflows, and base container images. When a core library like Diffusers fails to enforce its trust boundaries, downloading an unvetted model becomes as risky as executing an untrusted binary or running an unexamined shell script.

If an attacker successfully trick an enterprise pipeline into loading a compromised model repository, the blast radius extends well beyond the Python runtime environment. In typical corporate deployments, model loaders operate in environments with direct access to high-value resources, including:

  • Proprietary training data and internal model weights stored in attached cloud storage buckets.
  • Enterprise infrastructure credentials and API keys stored in environment variables.
  • Powerful GPU compute nodes that can be hijacked for unauthorized cryptomining or secondary lateral movement.
  • Internal network segments accessible to automated model-testing workers.

Remediation and Mitigation Guidance

The vulnerabilities were responsibly disclosed to Hugging Face maintainers and officially patched in Diffusers version 0.38.0, released in early May 2026. All organizations using the Diffusers library must update their environments immediately.

If your environment relies on automated dependency management, update your requirements files to mandate diffusers>=0.38.0.

For organizations unable to immediately roll out the version 0.38.0 patch across all production and development environments, project maintainers recommend enforcing strict operational guardrails:

  1. Restrict Model Sources: Only call DiffusionPipeline.from_pretrained using pretrained_model_name_or_path, custom_pipeline, or local snapshot paths originating from fully trusted, internally audited repositories.
  2. Audit External Pipelines: Never set custom_pipeline to point at a remote Hub repository that differs from the main pretrained_model_name_or_path without first manually reviewing the remote pipeline.py source code.
  3. Inspect Local Snapshots: Before invoking from_pretrained on locally cached or mirrored snapshots, programmatically inspect the directory tree for unexpected .py files. Pay specific attention to component subdirectories such as unet/ and scheduler/, as well as the root level of the snapshot repository.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call