On May 2, 2026, Hugging Face released Diffusers version 0.38.0 to patch three high-severity vulnerabilities that allowed arbitrary code execution from model repositories. The flaws, collectively named FaceHugger, bypassed the library's trust_remote_code parameter, which is designed to prevent untrusted code execution. CVE-2026-44827, the most severe of the three, scored 8.8 on CVSS. With over 8.1 million downloads in July 2026 alone, the impact window was substantial.
What Happened
Zafran Labs discovered that Diffusers loaded and executed code from model repositories before checking the trust_remote_code flag. This Time-of-Check to Time-of-Use (TOCTOU) race condition meant your security control ran after the threat had already executed. An attacker could craft a malicious model repository that executed arbitrary Python code during the initial load phase, before your application even evaluated whether to trust it.
The vulnerability chain worked like this: when your pipeline downloaded a model from Hugging Face, Diffusers fetched configuration files and supporting code. The library then loaded this code into memory and executed initialization routines. Only after these operations did it check whether trust_remote_code=False should block execution. By that point, the malicious payload had already run.
Timeline
Pre-May 2, 2026: Vulnerable versions of Diffusers were in production across thousands of AI pipelines. Organizations assumed trust_remote_code=False provided protection.
May 2, 2026: Hugging Face released Diffusers 0.38.0 with patches. No public disclosure of vulnerability details yet.
Discovery to Disclosure Window: Zafran Labs identified the TOCTOU flaw and reported it through responsible disclosure. The timing between discovery and patch release isn't public, but the coordinated release suggests standard 90-day disclosure practices.
Post-Patch: Organizations running older versions remained vulnerable. The 8.1 million downloads in July indicate rapid adoption, but also suggest many deployments still running unpatched versions.
Which Controls Failed
The core failure wasn't technical complexity; it was architectural. Your security control existed, but it ran in the wrong sequence.
Missing: Atomic Security Checks
The trust_remote_code parameter should have been evaluated before any code loading occurred. Instead, it acted as a post-execution gate. This violates the principle that security decisions must happen before the action they're meant to protect.
Missing: Input Validation at Trust Boundaries
Model repositories are external, untrusted inputs. Treating them as passive data rather than active code created a blind spot. Your pipeline should have validated and sandboxed all repository contents before any execution.
Missing: Dependency Integrity Verification
No cryptographic verification of model code integrity before execution. If you're loading Python from a remote repository, you need to verify its signature or hash against a known-good value before the interpreter touches it.
Missing: Least Privilege Execution
Model loading ran with the same privileges as your application. A properly designed system would load untrusted models in a restricted environment with minimal permissions.
What Standards Require
OWASP ASVS v4.0.3, Requirement 5.3.3: "Verify that the application validates, sanitizes, and escapes untrusted data before use." Model repository code is untrusted data. Loading it without validation fails this requirement.
NIST 800-53 Rev 5, SI-7 (Software, Firmware, and Information Integrity): "Employ integrity verification tools to detect unauthorized changes." You need cryptographic verification of model code before execution. The TOCTOU flaw meant no verification happened at the right time.
ISO/IEC 27001:2022, Annex A.8.24 (Use of Privileged Utility Programs): "The use of utility programs that might be capable of overriding system and application controls shall be restricted and tightly controlled." Model loading code that executes arbitrary Python qualifies as a privileged utility. It should run in a restricted context.
PCI DSS v4.0.1, Requirement 6.2.4: "Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks." TOCTOU vulnerabilities are a well-known attack class. Your development process should include checks for race conditions in security-critical code paths.
If you're running AI workloads that process payment card data or other regulated information, these requirements aren't optional. A vulnerability that allows arbitrary code execution creates a direct path to data exfiltration.
Lessons and Action Items
Immediate Actions
Upgrade Diffusers to version 0.38.0 or later. If you can't upgrade immediately, set trust_remote_code=False explicitly and audit which models your pipeline loads. Review your model sources, do you trust every repository in your dependency chain?
Architectural Changes
Move security checks before execution, not after. For any external code or data that your system loads:
- Verify integrity (signature or hash) before loading.
- Evaluate trust decisions before execution.
- Run untrusted code in sandboxed environments.
Treat model repositories like you treat third-party dependencies in your application code. You wouldn't pip install from an untrusted PyPI mirror without verification, apply the same rigor to AI models.
Process Changes
Add TOCTOU analysis to your code review checklist. When you see a security check (like trust_remote_code), verify it runs before the operation it protects, not after. This applies to file operations, network requests, and privilege checks throughout your codebase.
Implement supply chain verification for AI models. Maintain an approved list of model repositories. Require cryptographic signatures for models used in production. Log all model downloads and code executions for audit trails.
Testing Requirements
Build test cases that attempt to exploit the timing gap between check and use. If your security control can be bypassed by winning a race condition, it's not a control, it's a suggestion.
For AI pipelines specifically, test what happens when a model repository contains unexpected Python files. Does your system execute them? When? Under what privileges?
The FaceHugger vulnerabilities exposed a fundamental assumption: that model repositories are data, not code. Your security architecture needs to reflect reality, they're both.
