GHSA-98h9-4798-4q5v Diffusers has a `trust_remote_code` bypass via `custom_pipeline` and local custom components

• PyPI diffusers: < 0.38.0 → 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. All users on versions `=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