CVE-2026-44513

Diffusers is the a library for pretrained diffusion models. Prior to 0.38.0, a trust_remote_code bypass in DiffusionPipeline.from_pretrained allows arbitrary remote code execution despite the user passing trust_remote_code=False (or omitting it, which is the default). The vulnerability has three variants, all sharing the same root cause — the trust_remote_code gate was implemented inside DiffusionPipeline.download() rather than at the actual dynamic-module load site, so any code path that bypassed or short-circuited download() also bypassed the security check. DiffusionPipeline.from_pretrained('repoA', custom_pipeline='attacker/repoB', trust_remote_code=False) — the gate evaluated against repoA's file list rather than repoB's, so repoB's pipeline.py was loaded and executed. DiffusionPipeline.from_pretrained('/local/snapshot', custom_pipeline='attacker/repoB', trust_remote_code=False) — the local-path branch never invoked download(), so the gate was never reached and remote code from repoB executed. DiffusionPipeline.from_pretrained('/local/snapshot', trust_remote_code=False) where the snapshot contains custom component files (e.g. unet/my_unet_model.py) referenced from model_index.json — same root cause; the local path skipped download() and custom component code executed. This vulnerability is fixed in 0.38.0.

Diffusers is the a library for pretrained diffusion models. Prior to 0.38.0, a trust_remote_code bypass in DiffusionPipeline.from_pretrained allows arbitrary remote code execution despite the user passing trust_remote_code=False (or omitting it, which is the default). The vulnerability has three variants, all sharing the same root cause — the trust_remote_code gate was implemented inside DiffusionPipeline.download() rather than at the actual dynamic-module load site, so any code path that bypassed or short-circuited download() also bypassed the security check. DiffusionPipeline.from_pretrained('repoA', custom_pipeline='attacker/repoB', trust_remote_code=False) — the gate evaluated against repoA's file list rather than repoB's, so repoB's pipeline.py was loaded and executed. DiffusionPipeline.from_pretrained('/local/snapshot', custom_pipeline='attacker/repoB', trust_remote_code=False) — the local-path branch never invoked download(), so the gate was never reached and remote code from repoB executed. DiffusionPipeline.from_pretrained('/local/snapshot', trust_remote_code=False) where the snapshot contains custom component files (e.g. unet/my_unet_model.py) referenced from model_index.json — same root cause; the local path skipped download() and custom component code executed. This vulnerability is fixed in 0.38.0.

### Impact A `trust_remote_code` bypass in `DiffusionPipeline.from_pretrained` allows arbitrary remote code execution despite the user passing `trust_remote_code=False` (or omitting it, which is the default). The vulnerability has three variants, all sharing the same root cause — the `trust_remote_code` gate was implemented inside `DiffusionPipeline.download()` rather than at the actual dynamic-module load site, so any code path that bypassed or short-circuited `download()` also bypassed the security check: 1. **Cross-repo `custom_pipeline`.** `DiffusionPipeline.from_pretrained('repoA', custom_pipeline='attacker/repoB', trust_remote_code=False)` — the gate evaluated against `repoA`'s file list rather than `repoB`'s, so `repoB`'s `pipeline.py` was loaded and executed. 2. **Local snapshot + Hub `custom_pipeline`.** `DiffusionPipeline.from_pretrained('/local/snapshot', custom_pipeline='attacker/repoB', trust_remote_code=False)` — the local-path branch never invoked `download()`, so the gate was never reached and remote code from `repoB` executed. 3. **Local snapshot with custom components.** `DiffusionPipeline.from_pretrained('/local/snapshot', trust_remote_code=False)` where the snapshot contains custom component files (e.g. `unet/my_unet_model.py`) referenced from `model_index.json` — same root cause; the local path skipped `download()` and custom component code executed. Silent remote code execution on the victim's machine. Anyone calling `DiffusionPipeline.from_pretrained` with custom pipelines is impacted. ### Patches Yes. Fixed in **diffusers 0.38.0** via [PR #13448](https://github.com/huggingface/diffusers/pull/13448). All users on versions `< 0.38.0` should upgrade: ```bash pip install --upgrade "diffusers>=0.38.0" ``` The fix moves the `trust_remote_code` gate out of `DiffusionPipeline.download()` and into `get_cached_module_file` in `src/diffusers/utils/dynamic_modules_utils.py`, which is the actual chokepoint for every dynamic module load (local, Hub, or community mirror). All three variants now raise `ValueError` instead of executing untrusted code. ### Workarounds If upgrading immediately is not possible: - Only call `from_pretrained` with `pretrained_model_name_or_path`, `custom_pipeline`, and local snapshot directories from fully trusted sources that have been audited. - Do not pass `custom_pipeline=` pointing at a Hub repository different from the primary `pretrained_model_name_or_path` before reading its `pipeline.py`. - Before calling `from_pretrained` on a local snapshot, inspect the snapshot for unexpected `*.py` files, especially under component subdirectories (`unet/`, `scheduler/`, etc.) and at the snapshot root. These are mitigations, not fixes — the only complete remediation is upgrading to 0.38.0. ### Resources - **Fix:** https://github.com/huggingface/diffusers/pull/13448 - **Original issue:** https://github.com/huggingface/diffusers/issues/13446 - **Release notes:** https://github.com/huggingface/diffusers/releases/tag/v0.38.0 - **CWE-94:** https://cwe.mitre.org/data/definitions/94.html