FaceHugger: Diffusers Bypasses trust_remote_code

What are the FaceHugger flaws in Diffusers?

According to The Hacker News (August 3, 2026), they are three flaws in the Python library that loads diffusion models in production and CI pipelines. Zafran Labs named them FaceHugger. Diffusers was downloaded more than 8.1 million times in July 2026 per pepy.tech.

trust_remote_code is the option deciding whether the library runs Python code shipped in a model repository (custom pipelines). By default it is off: the user must accept the risk. FaceHugger shows three ways to run code despite this protection.

What are the three CVEs?

Zafran links each variant to a TOCTOU (time-of-check to time-of-use) defect, because the trust check runs only against the first request. For the researchers, the root cause is that the trust check lives "entirely in the first phase".

Which versions are affected?

The fix is in Diffusers 0.38.0, released in early May 2026. The article does not name the range of affected versions: it says any user who calls DiffusionPipeline.from_pretrained with custom pipelines is concerned. Consider any version before 0.38.0 as needing an update.

What if you cannot update right away?

The maintainers offer workarounds:

• use from_pretrained only with audited, fully trusted sources;
• do not point custom_pipeline at a different Hub repository without first reviewing its pipeline file;
• inspect local snapshots for unexpected .py files, especially in component subdirectories and at the snapshot root.

What should you do for any application that loads third-party models?

1. Update Diffusers to 0.38.0 or later, and the huggingface_hub library with it.
2. Load models in an isolated environment: container or ephemeral machine with no credentials, no internal network access and no access to application secrets.
3. Pin revisions: reference a specific reviewed commit hash, not a moving branch. A repository modified after your first fetch must not be reloaded automatically.
4. Prefer pure data formats (.safetensors) to formats that can run code (pickle). If custom code is unavoidable, review it and vendor it into your repository rather than pulling it at runtime.
5. Scan downloaded files like any untrusted binary and look for .py files you do not expect in a snapshot.
6. Reduce the loading process's rights: no cloud keys, tokens or unnecessary secrets in its environment.
7. Log the models and revisions loaded: who, when, from which repository.

How do you test your pipeline's model loading?

In an isolated test environment and with authorization.

1. Inventory: list every from_pretrained call, every custom_pipeline and every repository referenced, with its revision.
2. Version: check the Diffusers version in each image (pip show diffusers).
3. Sentinel repository: create a test repository containing a pipeline file that writes a harmless marker file, and load it without trust_remote_code. On a fixed version, nothing should run.
4. Blast radius: from the loading process, list the reachable credentials, networks and files. Every reachable item is a lateral movement path.
5. Repository update: modify the test repository between two loads and verify that pinned revisions prevent the change from applying.
6. Alerts: does an unexpected code execution in the loader raise an alert?

Why is a TOCTOU defect so common in this kind of loading?

Because loading a model happens in several steps, and each step can read a different state. In Diffusers' case, the library first downloads a configuration, checks that it does not require remote code, then downloads the rest of the snapshot with a second request. If the repository content changes between the two, or if the second step reads a path the first did not examine, the check applies to something other than what is finally executed.

The design remedy is to make the check atomic: fetch a specific revision, freeze it, verify that precise object, then load only it. For your own loaders, the same principle applies to any remote artifact: you verify what you execute, not what you saw a minute earlier.

For a library user, the consequence is not to treat a default option as a guarantee. Pinning revisions and isolating the loading process protect even when an internal check is bypassed.

It also argues for keeping an inventory of every place your code reaches out to a model hub at runtime. Many teams discover loaders hidden in notebooks, demo scripts and old microservices only when an advisory forces them to look. A one-time search of your repositories for from_pretrained and custom_pipeline turns the next advisory from a scramble into a ten-minute check.

What is the link with the AI supply chain?

FaceHugger follows the intrusion described in the article on Hugging Face, OpenAI and autonomous agents, where remote-code dataset loaders served as the entry point. Datasets, model weights, tokenizers and pipeline code form a supply chain that must be treated like npm or PyPI: untrusted remote artifacts, pinned versions, execution in isolation. The AI ecosystem has younger tooling and weaker defaults, so the effort of applying this discipline falls to you.

A boolean option like trust_remote_code is not enough as a security boundary: the question is by how many paths code can get around the check. See the AI agent security page.

CleanIssue's Agent Red Team Express (EUR 1,900, 5 days) tests your AI agents and their tool and model chains: see the offer. A free 30-minute discovery call is enough to check which remote models your pipeline allows to run code.