Описание
Diffusers has a trust_remote_code bypass via custom_pipeline and local custom components
Background
This vulnerability is found in the DiffusionPipeline.from_pretrained flow, which is used to load a pipeline from the HuggingFace Hub.
This function accepts an optional custom_pipeline keyword argument: the name of a Python file in the repo that contains a custom class inheriting from DiffusionPipeline. An equivalent flow is triggered when the _class_name field in model_index.json (the repo config file) is set to a custom class.
Any attempt to use a custom pipeline throws the following exception, requesting that trust_remote_code is also passed:
The vulnerability is a silent RCE - it allows arbitrary code to be loaded through the custom_pipeline flow from a Hub repo, with no custom_pipeline or trust_remote_code kwargs and nothing suspicious in the config. The from_pretrained call succeeds and returns a functional pipeline.
Naive Flow
First, all relevant arguments are popped from kwargs and stored in local variables.
Given a pretrained_model_name_or_path that is a Hub repo ID, DiffusionPipeline.download() is called. This function serves two roles: it orchestrates downloading relevant model files, and it is the security gatekeeper for trust_remote_code. It is called even if the model is already cached; in that case it exits early. If the repo contains custom code, it checks whether trust_remote_code was passed and raises otherwise:
It then runs _get_pipeline_class, which returns the class object of the pipeline in order to inspect its __init__ signature and determine which component files need to be downloaded. As part of building the allow_patterns list used to filter the snapshot download to necessary files only, the custom pipeline file is explicitly included if present:
The function then checks if all expected files are already present, and either exits early or triggers a snapshot download with those patterns.
The next step in from_pretrained is loading the pipeline class a second time, this time to actually instantiate it. Before calling _get_pipeline_class again, _resolve_custom_pipeline_and_cls is called to translate the custom_pipeline name into a local path, since the files have already been downloaded:
When custom_class_name is None (i.e. custom_pipeline was given as a kwarg rather than via the config), _get_pipeline_class will scan the file and automatically identify the class that subclasses DiffusionPipeline.
Once this is done, _get_pipeline_class is invoked with the resolved local path, which loads the custom code, retrieves the class object, and proceeds with instantiation.
The Vulnerability
_resolve_custom_pipeline_and_cls receives custom_pipeline from the kwargs - when not supplied it defaults to None. That None is used in string formatting: f"{None}.py" = "None.py".
If the repo contains a file with this name, it will be detected as a custom pipeline.
This is only reached on the second invocation of _get_pipeline_class (inside from_pretrained, after download() returns). The trust_remote_code check lives entirely in download(), which evaluated custom_pipeline is None -> False and skipped it. By the time _resolve_custom_pipeline_and_cls runs, it is no longer relevant.
As a bonus, None.py even gets downloaded automatically when the model isn't cached yet. This isn't strictly required - it is quite plausible that the victim has already run hf download <model> and has all files locally - but if they haven't, revisiting the allow_patterns line above shows it makes the same error: f"{None}.py" = "None.py" is added to allow_patterns and fetched.
What should None.py contain? To avoid breaking the pipeline load, it must define a class inheriting from DiffusionPipeline. To avoid leaving suspicious clues in the config, that class should shadow one that already exists in diffusers. The following satisfies both requirements:
With this, model_index.json can contain "_class_name": "FluxPipeline" - appearing to use the standard diffusers class - and the resulting pipeline is fully functional (it is also functional when running as a local directory). This has been verified against an extracted version of DDUF/tiny-flux-dev-pipe-dduf.
All the attacker needs the victim to run is:
PoC
- Upload this zip as a model to the hub. https://drive.google.com/file/d/1mULARMLJJUTCi57xIv0wtDauko-JW0h7/view?usp=sharing
- Run
DiffusionPipeline.from_pretrainedon the uploaded model hub identifier. - RCE occured;
/tmp/pwnedwas created. If you are running the exploit on windows, change the path touched inNone.py.
Impact
The vulnerability is a silent RCE - it allows arbitrary code to be loaded through the custom_pipeline flow from a Hub repo, with no custom_pipeline or trust_remote_code kwargs and nothing suspicious in the config. The from_pretrained call succeeds and returns a functional pipeline.
Occurrences
Patches
Yes. Fixed in diffusers 0.38.0 via PR #13448. All users on versions < 0.38.0 should upgrade:
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 when trust_remote_code=False instead of executing untrusted code.
Workarounds
If upgrading immediately is not possible:
- Only call
from_pretrainedwithpretrained_model_name_or_path,custom_pipeline, and local snapshot directories from sources you fully trust and have audited. - Do not pass
custom_pipeline=pointing at a Hub repository different from the primarypretrained_model_name_or_pathunless you have read itspipeline.py. - Before calling
from_pretrainedon a local snapshot, inspect the snapshot for unexpected*.pyfiles, especially under component subdirectories (unet/,scheduler/, etc.) and at the snapshot root.
Why this should have a dedicated CVE
GHSA-j7w6-vpvq-j3gm is a distinct defect from CVE-2026-44513. CVE-2026-44513 is a misplaced-security-gate bug requiring a user-supplied custom_pipeline argument or a config entry declaring custom code. GHSA-j7w6 is a string-formatting bug where the default custom_pipeline=None is interpolated into the filename None.py, allowing silent RCE on a fully default from_pretrained('repo') call with no kwargs and a model_index.json that shadows a legitimate class. The root cause root cause and trigger are different, although the fix applied to address CVE-2026-44513 also addresses this vulnerability.
Ссылки
- https://github.com/huggingface/diffusers/security/advisories/GHSA-j7w6-vpvq-j3gm
- https://nvd.nist.gov/vuln/detail/CVE-2026-44827
- https://github.com/huggingface/diffusers/pull/13448
- https://github.com/huggingface/diffusers/commit/a37f6f8394ac2a7ee8360c3abea811efe54512b1
- https://github.com/huggingface/diffusers/releases/tag/v0.38.0
- https://github.com/pypa/advisory-database/tree/main/vulns/diffusers/PYSEC-2026-41.yaml
Пакеты
diffusers
< 0.38.0
0.38.0
Связанные уязвимости
Diffusers is the a library for pretrained diffusion models. Prior to 0.38.0, diffusers 0.37.0 allows remote code execution without the trust_remote_code=True safeguard when loading pipelines from Hugging Face Hub repositories. The _resolve_custom_pipeline_and_cls function in pipeline_loading_utils.py performs string interpolation on the custom_pipeline parameter using f"{custom_pipeline}.py". When custom_pipeline is not supplied by the user, it defaults to None, which Python interpolates as the literal string "None.py". If an attacker publishes a Hub repository containing a file named None.py with a class that subclasses DiffusionPipeline, the file is automatically downloaded and executed during a standard DiffusionPipeline.from_pretrained() call with no additional keyword arguments. The trust_remote_code check in DiffusionPipeline.download() is bypassed because it evaluates custom_pipeline is not None as False (since the kwarg was never supplied), while the downstream code path th...
Diffusers is the a library for pretrained diffusion models. Prior to 0.38.0, diffusers 0.37.0 allows remote code execution without the trust_remote_code=True safeguard when loading pipelines from Hugging Face Hub repositories. The _resolve_custom_pipeline_and_cls function in pipeline_loading_utils.py performs string interpolation on the custom_pipeline parameter using f"{custom_pipeline}.py". When custom_pipeline is not supplied by the user, it defaults to None, which Python interpolates as the literal string "None.py". If an attacker publishes a Hub repository containing a file named None.py with a class that subclasses DiffusionPipeline, the file is automatically downloaded and executed during a standard DiffusionPipeline.from_pretrained() call with no additional keyword arguments. The trust_remote_code check in DiffusionPipeline.download() is bypassed because it evaluates custom_pipeline is not None as False (since the kwarg was never supplied), while the downstream code path that