### 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
### 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
Update diffusers to 0.38.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDiffusers has a `trust_remote_code` bypass via `custom_pipeline` and local custom components affects diffusers (pip). Severity is high. ### 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
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| diffuserspip | <0.38.0 | 0.38.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate diffusers to 0.38.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDiffusers has a `trust_remote_code` bypass via `custom_pipeline` and local custom components affects diffusers (pip). Severity is high. ### 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
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| diffuserspip | <0.38.0 | 0.38.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard