Datasets through 5.0.0, fixed in commit f989ef9, contains a path traversal vulnerability in folder-based dataset builders where the filename metadata field is not properly validated before being joined to the dataset directory. Attackers can supply crafted filename values with directory traversal sequences to read arbitrary local files, which are then embedded into output when savetodisk or pushtohub is called.

A vulnerability in the LightGlue model loading path of huggingface/transformers version 5.2.0 allows an attacker-controlled model repository to execute arbitrary code during model initialization. The issue arises because the trustremotecode parameter, intended to prevent remote code execution, is overridden by untrusted serialized configuration data in a nested code path. Specifically, when loading a LightGlue model using AutoModel.frompretrained() with trustremotecode=False, the LightGlueConfig reads the trustremotecode value from the untrusted config.json file and propagates it into nested AutoConfig.frompretrained() calls. This results in the execution of attacker-provided Python modules, even when the victim explicitly disables remote code execution. The vulnerability poses a high risk for environments such as API inference servers, research notebooks, CI/CD pipelines, and model evaluation workers, potentially leading to credential theft, lateral movement, or persistence/backdoor deployment.

A critical remote code execution vulnerability exists in all versions of the HuggingFace transformers library prior to version 5.3.0. The vulnerability allows an attacker to craft a malicious config.json file containing the attnimplementationinternal field set to an attacker-controlled HuggingFace Hub repository ID. When a victim loads this model using the standard AutoModelForCausalLM.frompretrained() API, the library downloads and executes arbitrary Python code from the attacker's repository with the victim's full OS privileges. This issue arises due to unfiltered deserialization of configuration attributes, insufficient sanitization of internal fields, and unsandboxed execution of downloaded kernels. The vulnerability bypasses the trustremotecode security mechanism, is invisible to the victim, and exploits the standard documented usage pattern, making it particularly severe. Users are advised to upgrade to version 5.3.0 or later to mitigate this issue.

Background

This vulnerability is found in the diffusers package - the transformers-equivalent library for diffusion models.

It is found in the DiffusionPipeline.frompretrained flow, which is used to load a pipeline from the HuggingFace Hub.

This function has a trustremotecode guard: if the repository’s modelindex.json references a custom pipeline class defined in a .py file in the repo, the load is blocked unless trustremotecode=True is explicitly passed:

ValueError: The repository for attacker/repo contains custom code in pipeline.py which must be executed to correctly load the model. You can inspect the repository content at https://hf.co/attacker/repo/blob/main/pipeline.py. Please pass the argument trustremotecode=True to allow custom code to be run.

The vulnerability allows arbitrary code execution through the custom pipeline flow from a Hub repo, with no custompipeline or trustremotecode kwargs passed. The frompretrained call succeeds and returns a functional pipeline.

---

Naive Flow

DiffusionPipeline.frompretrained begins by popping all relevant arguments from kwargs into local variables, then calls DiffusionPipeline.download() to fetch the repo files:

python pipelineutils.py:853 cachedfolder = cls.download( pretrainedmodelnameorpath, ... custompipeline=custompipeline, trustremotecode=trustremotecode, ... )

Inside download(), modelindex.json is fetched first as a standalone file via hfhubdownload:

python pipelineutils.py:1636 configfile = hfhubdownload( pretrainedmodelname, cls.configname, ... ) configdict = cls.dictfromjsonfile(configfile)

This config is used to detect custom pipeline code and enforce the trust check:

python pipelineutils.py:1672 if custompipeline is None and isinstance(configdict["classname"], (list, tuple)): custompipeline = configdict["classname"][0]

loadpipefromhub = custompipeline is not None and f"{custompipeline}.py" in filenames

if loadpipefromhub and not trustremotecode: raise ValueError(...)

After the check passes, snapshotdownload then fetches all files and saves them to disk:

python pipelineutils.py:1778 cachedfolder = snapshotdownload( pretrainedmodelname, ... revision=revision, allowpatterns=allowpatterns, ... )

Back in frompretrained, the config is read a second time from the downloaded snapshot, andresolvecustompipelineandcls reads the config to re-check if custom code needs to be loaded:

python pipelineloadingutils.py:974 def resolvecustompipelineandcls(folder, config, custompipeline): customclassname = None if os.path.isfile(os.path.join(folder, f"{custompipeline}.py")): custompipeline = os.path.join(folder, f"{custompipeline}.py") elif isinstance(config["classname"], (list, tuple)) and os.path.isfile( os.path.join(folder, f"{config['classname'][0]}.py") ): custompipeline = os.path.join(folder, f"{config['classname'][0]}.py") customclassname = config["classname"][1]

return custompipeline, customclassname

If the config points to a .py file, it is imported.

---

The Vulnerability

hfhubdownload and snapshotdownload are two independent HTTP calls to the Hub, both resolving the repository’s default branch (if revision=None) to its current HEAD at call time. There is no atomicity guarantee between them - if the repository is updated between the two calls, they will resolve to different commits and download different content, with no warning displayed to the user.

The trust check in download() operates on the content fetched by hfhubdownload (commit A). The snapshotdownload call that immediately follows can silently fetch a newer commit (commit B). The config in the newer commit will be the one parsed by resolvecustompipelineandcls.

Therefore, it’s possible to introduce remote code into the repo between the two calls, bypassing the trust check.

The race window is everything between the two Hub calls inside download():

python pipelineutils.py:1636 configfile = hfhubdownload(...) # ← sees commit A, trust check passes

... filenames processing, pattern building, pipelineiscached check ... ~~~ ATTACKER PUSHES COMMIT B HERE ~~~

pipelineutils.py:1778 cachedfolder = snapshotdownload(...) # ← sees commit B, downloads pipeline.py

For the exploit, commit A carries a clean config with classname as a plain string, which causes loadpipefromhub to be False and the trust check to pass. Commit B changes classname to a list and adds pipeline.py:

Commit A - modelindex.json:

json { "classname": "FluxPipeline", "diffusersversion": "0.31.0" }

Commit B - modelindex.json:

json { "classname": ["pipeline", "FluxPipeline"], "diffusersversion": "0.31.0" }

When frompretrained reads the snapshot after download() returns, config["classname"] is now a list, pipeline.py exists on disk (fetched by snapshotdownload), and resolvecustompipelineandcls resolves custompipeline to the local path of that file. getpipelineclass then imports it - with no trust check at this point in the code.

---

PoC

1. Create a Hub repo with commit A’s modelindex.json (plain string classname). 2. Run DiffusionPipeline.frompretrained("attacker/repo") with a breakpoint set at pipelineutils.py:1778 (the snapshotdownload call). This is for the window to be large enough to manually respond to it. 3. When execution pauses at the breakpoint, push commit B: update modelindex.json to use a list classname and add pipeline.py. 4. Resume execution. 5. snapshotdownload fetches commit B; /tmp/pwned is written during the subsequent getpipelineclass call.

---

Constraints

- Does not apply when revision is pinned to a specific commit hash - both Hub calls resolve to the same content. - Does not apply when loading from a local directory. - If all expected files are already present in the local HF cache, download() returns early before reaching snapshotdownload (line 1767 early-return), closing the race window. The exploit therefore requires a first (or forced) download.

---

Exploitability

The window between the two calls is very short. Local testing resulted in a window of approximately ~0.5 seconds for the attacker to push the change. This is, of course, unfeasible to accomplish for each and every new download. However, given a popular repo with many downloads per day, one may achieve statistical success by changing the repo’s state every once in a while or every few seconds, with some percentage of downloaders falling on the exact window.

---

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 custompipeline or trustremotecode kwargs. The frompretrained call succeeds and returns a fully functional pipeline.

Impact

A trustremotecode bypass in DiffusionPipeline.frompretrained allows arbitrary remote code execution despite the user passing trustremotecode=False (or omitting it, which is the default). The vulnerability has three variants, all sharing the same root cause — the trustremotecode 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 custompipeline. DiffusionPipeline.frompretrained('repoA', custompipeline='attacker/repoB', trustremotecode=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 custompipeline. DiffusionPipeline.frompretrained('/local/snapshot', custompipeline='attacker/repoB', trustremotecode=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.frompretrained('/local/snapshot', trustremotecode=False) where the snapshot contains custom component files (e.g. unet/myunetmodel.py) referenced from modelindex.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.frompretrained with custom pipelines is impacted.

Patches

Yes. Fixed in diffusers 0.38.0 via PR #13448. All users on versions < 0.38.0 should upgrade:

bash pip install --upgrade "diffusers>=0.38.0"

The fix moves the trustremotecode gate out of DiffusionPipeline.download() and into getcachedmodulefile in src/diffusers/utils/dynamicmodulesutils.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 frompretrained with pretrainedmodelnameorpath, custompipeline, and local snapshot directories from fully trusted sources that have been audited. - Do not pass custompipeline= pointing at a Hub repository different from the primary pretrainedmodelnameorpath before reading its pipeline.py. - Before calling frompretrained 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

Background

This vulnerability is found in the DiffusionPipeline.frompretrained flow, which is used to load a pipeline from the HuggingFace Hub.

This function accepts an optional custompipeline 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 classname field in modelindex.json (the repo config file) is set to a custom class.

Any attempt to use a custom pipeline throws the following exception, requesting that trustremotecode is also passed:

python DiffusionPipeline.frompretrained( pretrainedmodelnameorpath='ido-shani/custom-pipeline', custompipeline="custom" )

ValueError: The repository for ido-shani/custom-pipeline contains custom code in custom.py which must be executed to correctly load the model. You can inspect the repository content at https://hf.co/ido-shani/custom-pipeline/blob/main/custom.py. Please pass the argument trustremotecode=True to allow custom code to be run.

The vulnerability is a silent RCE - it allows arbitrary code to be loaded through the custom\pipeline flow from a Hub repo, with no custompipeline or trustremotecode kwargs and nothing suspicious in the config. The frompretrained call succeeds and returns a functional pipeline.

Naive Flow

First, all relevant arguments are popped from kwargs and stored in local variables.

Given a pretrainedmodelnameorpath 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 trustremotecode. 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 trustremotecode was passed and raises otherwise:

python pipelineutils.py:1645-1652 loadpipefromhub = custompipeline is not None and f"{custompipeline}.py" in filenames

...

if loadpipefromhub and not trustremotecode: raise ValueError(...)

It then runs getpipelineclass, 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 allowpatterns list used to filter the snapshot download to necessary files only, the custom pipeline file is explicitly included if present:

python pipelineutils.py:1707 allowpatterns += [f"{custompipeline}.py"] if f"{custompipeline}.py" in filenames else []

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 frompretrained is loading the pipeline class a second time, this time to actually instantiate it. Before calling getpipelineclass again, resolvecustompipelineandcls is called to translate the custompipeline name into a local path, since the files have already been downloaded:

python pipelineloadingutils.py:965-974 def resolvecustompipelineandcls(folder, config, custompipeline): customclassname = None if os.path.isfile(os.path.join(folder, f"{custompipeline}.py")): custompipeline = os.path.join(folder, f"{custompipeline}.py") elif isinstance(config["classname"], (list, tuple)) and os.path.isfile( os.path.join(folder, f"{config['classname'][0]}.py") ): custompipeline = os.path.join(folder, f"{config['classname'][0]}.py") customclassname = config["classname"][1]

return custompipeline, customclassname

When customclassname is None (i.e. custompipeline was given as a kwarg rather than via the config), getpipelineclass will scan the file and automatically identify the class that subclasses DiffusionPipeline.

Once this is done, getpipelineclass is invoked with the resolved local path, which loads the custom code, retrieves the class object, and proceeds with instantiation.

The Vulnerability

resolvecustompipelineandcls receives custompipeline 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 getpipelineclass (inside frompretrained, after download() returns). The trust\remote\code check lives entirely in download(), which evaluated custompipeline is None -> False and skipped it. By the time resolvecustompipelineandcls 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 allowpatterns line above shows it makes the same error: f"{None}.py" = "None.py" is added to allowpatterns 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:

python from diffusers import FluxPipeline as FluxPipeline

class FluxPipeline(FluxPipeline): pass

INSERT MALICIOUS CODE HERE import pathlib pathlib.Path("/tmp/pwned").writetext(":)")

With this, modelindex.json can contain "classname": "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:

python from diffusers import DiffusionPipeline

pipeline = DiffusionPipeline.frompretrained('ido-shani/none-py-trust-remote-code-bypass')

PoC

- Upload this zip as a model to the hub. https://drive.google.com/file/d/1mULARMLJJUTCi57xIv0wtDauko-JW0h7/view?usp=sharing - Run DiffusionPipeline.frompretrained on the uploaded model hub identifier. - RCE occured; /tmp/pwned was created. If you are running the exploit on windows, change the path touched in None.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 custompipeline or trustremotecode kwargs and nothing suspicious in the config. The frompretrained call succeeds and returns a functional pipeline.

Occurrences

https://github.com/huggingface/diffusers/blob/e1b5db52bda85d47a4f8f75954f77e672a8f7f1c/src/diffusers/pipelines/pipelineloadingutils.py#L976

Patches

Yes. Fixed in diffusers 0.38.0 via PR #13448. All users on versions < 0.38.0 should upgrade:

bash pip install --upgrade "diffusers>=0.38.0"

The fix moves the trustremotecode gate out of DiffusionPipeline.download() and into getcachedmodulefile in src/diffusers/utils/dynamicmodulesutils.py, which is the actual chokepoint for every dynamic module load (local, Hub, or community mirror). All three variants now raise ValueError when trustremotecode=False instead of executing untrusted code.

Workarounds

If upgrading immediately is not possible:

- Only call frompretrained with pretrainedmodelnameorpath, custompipeline, and local snapshot directories from sources you fully trust and have audited. - Do not pass custompipeline= pointing at a Hub repository different from the primary pretrainedmodelnameorpath unless you have read its pipeline.py. - Before calling frompretrained on a local snapshot, inspect the snapshot for unexpected .py files, 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 custompipeline argument or a config entry declaring custom code. GHSA-j7w6 is a string-formatting bug where the default custompipeline=None is interpolated into the filename None.py, allowing silent RCE on a fully default frompretrained('repo') call with no kwargs and a modelindex.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.

LeRobot through 0.5.1 contains an unsafe deserialization vulnerability in the async inference pipeline where pickle.loads() is used to deserialize data received over unauthenticated gRPC channels without TLS in the policy server and robot client components. An unauthenticated network-reachable attacker can achieve arbitrary code execution on the server or client by sending a crafted pickle payload through the SendPolicyInstructions, SendObservations, or GetActions gRPC calls.

A vulnerability in the HuggingFace Transformers library, specifically in the Trainer class, allows for arbitrary code execution. The loadrngstate() method in src/transformers/trainer.py at line 3059 calls torch.load() without the weightsonly=True parameter. This issue affects all versions of the library supporting torch>=2.2 when used with PyTorch versions below 2.6, as the safeglobals() context manager provides no protection in these versions. An attacker can exploit this vulnerability by supplying a malicious checkpoint file, such as rngstate.pth, which can execute arbitrary code when loaded. The issue is resolved in version v5.0.0rc3.

A weakness has been identified in huggingface smolagents 1.25.0.dev0. This affects the function evaluateaugassign/evaluatecall/evaluatewith of the file src/smolagents/localpythonexecutor.py of the component Incomplete Fix CVE-2025-9959. This manipulation causes code injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

A weakness has been identified in huggingface smolagents 1.24.0. Impacted is the function requests.get/requests.post of the component LocalPythonExecutor. Executing a manipulation can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Hugging Face Transformers GLM4 Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of weights. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28309.

Hugging Face Transformers HuBERT convertconfig Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must convert a malicious checkpoint.

The specific flaw exists within the convertconfig function. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-28253.

Hugging Face Transformers megatrongpt2 Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of checkpoints. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-27984.

Hugging Face Transformers Perceiver Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25423.

Hugging Face Transformers SEW convertconfig Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must convert a malicious checkpoint.

The specific flaw exists within the convertconfig function. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-28251.

Hugging Face Transformers SEW-D convertconfig Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must convert a malicious checkpoint.

The specific flaw exists within the convertconfig function. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the current user.

. Was ZDI-CAN-28252.

Hugging Face Transformers Transformer-XL Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25424.

Hugging Face Transformers X-CLIP Checkpoint Conversion Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of checkpoints. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28308.

Hugging Face Smolagents version 1.20.0 contains an XPath injection vulnerability in the searchitemctrlf function located in src/smolagents/visionwebbrowser.py. The function constructs an XPath query by directly concatenating user-supplied input into the XPath expression without proper sanitization or escaping. This allows an attacker to inject malicious XPath syntax that can alter the intended query logic. The vulnerability enables attackers to bypass search filters, access unintended DOM elements, and disrupt web automation workflows. This can lead to information disclosure, manipulation of AI agent interactions, and compromise the reliability of automated web tasks. The issue is fixed in version 1.22.0.

The huggingface/transformers library, versions prior to 4.53.0, is vulnerable to Regular Expression Denial of Service (ReDoS) in the AdamWeightDecay optimizer. The vulnerability arises from the douseweightdecay method, which processes user-controlled regular expressions in the includeinweightdecay and excludefromweightdecay lists. Malicious regular expressions can cause catastrophic backtracking during the re.search call, leading to 100% CPU utilization and a denial of service. This issue can be exploited by attackers who can control the patterns in these lists, potentially causing the machine learning task to hang and rendering services unresponsive.

A vulnerability was identified in huggingface LeRobot up to 0.3.3. Affected by this vulnerability is an unknown functionality of the file lerobot/common/robotdevices/robots/lekiwiremote.py of the component ZeroMQ Socket Handler. The manipulation leads to missing authentication. The attack can only be initiated within the local network. The vendor was contacted early about this disclosure but did not respond in any way.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically within the normalizenumbers() method of the EnglishNormalizer class. This vulnerability affects versions up to 4.52.4 and is fixed in version 4.53.0. The issue arises from the method's handling of numeric strings, which can be exploited using crafted input strings containing long sequences of digits, leading to excessive CPU consumption. This vulnerability impacts text-to-speech and number normalization tasks, potentially causing service disruption, resource exhaustion, and API vulnerabilities.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically affecting the MarianTokenizer's removelanguagecode() method. This vulnerability is present in version 4.52.4 and has been fixed in version 4.53.0. The issue arises from inefficient regex processing, which can be exploited by crafted input strings containing malformed language code patterns, leading to excessive CPU consumption and potential denial of service.

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the Hugging Face Transformers library, specifically in the converttfweightnametoptweightname() function. This function, responsible for converting TensorFlow weight names to PyTorch format, uses a regex pattern /[^/]([^/])/ that can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. The vulnerability affects versions up to 4.51.3 and is fixed in version 4.53.0. This issue can lead to service disruption, resource exhaustion, and potential API service vulnerabilities, impacting model conversion processes between TensorFlow and PyTorch formats.

A sandbox escape vulnerability was identified in huggingface/smolagents version 1.14.0, allowing attackers to bypass the restricted execution environment and achieve remote code execution (RCE). The vulnerability stems from the localpythonexecutor.py module, which inadequately restricts Python code execution despite employing static and dynamic checks. Attackers can exploit whitelisted modules and functions to execute arbitrary code, compromising the host system. This flaw undermines the core security boundary intended to isolate untrusted code, posing risks such as unauthorized code execution, data leakage, and potential integration-level compromise. The issue is resolved in version 1.17.0.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically within the DonutProcessor class's token2json() method. This vulnerability affects versions 4.50.3 and earlier, and is fixed in version 4.52.1. The issue arises from the regex pattern <s(.?)> which can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. This vulnerability can lead to service disruption, resource exhaustion, and potential API service vulnerabilities, impacting document processing tasks using the Donut model.

Hugging Face Transformers versions up to 4.49.0 are affected by an improper input validation vulnerability in the imageutils.py file. The vulnerability arises from insecure URL validation using the startswith() method, which can be bypassed through URL username injection. This allows attackers to craft URLs that appear to be from YouTube but resolve to malicious domains, potentially leading to phishing attacks, malware distribution, or data exfiltration. The issue is fixed in version 4.52.1.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically in the getimports() function within dynamicmoduleutils.py. This vulnerability affects versions 4.49.0 and is fixed in version 4.51.0. The issue arises from a regular expression pattern \stry\s:.?except.?: used to filter out try/except blocks from Python code, which can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. This vulnerability can lead to remote code loading disruption, resource exhaustion in model serving, supply chain attack vectors, and development pipeline disruption.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically in the getconfigurationfile() function within the transformers.configurationutils module. The affected version is 4.49.0, and the issue is resolved in version 4.51.0. The vulnerability arises from the use of a regular expression pattern config\.(.)\.json that can be exploited to cause excessive CPU consumption through crafted input strings, leading to catastrophic backtracking. This can result in model serving disruption, resource exhaustion, and increased latency in applications using the library.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the huggingface/transformers repository, specifically in version 4.49.0. The vulnerability is due to inefficient regular expression complexity in the SETTINGRE variable within the transformers/commands/chat.py file. The regex contains repetition groups and non-optimized quantifiers, leading to exponential backtracking when processing 'almost matching' payloads. This can degrade application performance and potentially result in a denial-of-service (DoS) when handling specially crafted input strings. The issue is fixed in version 4.51.0.