# Transformers get_imports ReDoS Exposure

- **Severity:** Medium
- **Signature ID:** `3f9c1d7e-6b24-4a58-9e0d-7c41b8ad52f6`
- **MITRE ATLAS:** AML.T0029 (Denial of AI Service)
- **OWASP:** LLM10 (Unbounded Consumption), LLM03 (Supply Chain)

## Summary

A regular expression inside the Transformers library's get_imports() function can be forced into extremely slow, pathological matching if it processes attacker-crafted module source. This affects versions 4.49.x and is fixed in 4.51.0. This rule does not detect the slowdown itself; it flags situations where the vulnerable code path is reachable with untrusted input.

## How the attack works

An attacker needs their own Python module source to reach get_imports() so the vulnerable regex parses it. The most common route is a host running with trust_remote_code=True (or --trust-remote-code), the documented setting that tells Transformers or a model-serving tool to execute custom code pulled from the Hugging Face Hub. From there, a crafted module file containing a string shaped to trigger catastrophic backtracking in the try/except-matching regex can hang the process on CPU, effectively a denial of service. The rule also flags command lines that directly reference the vulnerable function or file, which look like proof-of-concept exploitation, and installer commands that pin Transformers to a known-vulnerable version range.

## Why it matters

A successful trigger ties up CPU on the host parsing a single crafted module, which can stall or hang model-serving processes and degrade or deny service for anyone depending on that inference endpoint.

## What you can do

- Upgrade Transformers to 4.51.0 or later wherever practical.
- Where trust_remote_code=True is required for legitimate Hub models, isolate those workloads and monitor CPU usage for hosts running with this flag.
- Treat a match as 'vulnerable code is reachable,' not confirmed exploitation: check the host's actual CPU/wall-time behavior and installed Transformers version before escalating.
- Audit CI and deployment pipelines that intentionally pin transformers==4.49.x or 4.50.x and confirm they never parse untrusted module source.

## Known benign look-alikes

- ML engineers loading community Hugging Face models that legitimately require custom code (trust_remote_code=True is the documented, required setting for a large fraction of Hub models) - this is the dominant benign case and is why the action is report, not block.
- vLLM, text-generation-inference, lmdeploy or SGLang deployments where --trust-remote-code is baked into the standard launch configuration.
- CI or reproducibility pipelines that deliberately pin transformers==4.49.0 or 4.50.x for artifact parity, on hosts where get_imports() only ever parses first-party module source.
- Security researchers or platform teams reproducing the advisory locally; the command line is indistinguishable from exploitation.
- Vendored copies of transformers whose own test files are executed outside a recognised test runner and therefore evade filter_test_runner.
- A hit is an exposure signal only - the rule cannot observe catastrophic backtracking, so CPU exhaustion must be confirmed from host metrics.

## References

- https://github.com/huggingface/transformers/blob/main/src/transformers/dynamic_module_utils.py
- https://github.com/huggingface/transformers/releases/tag/v4.51.0
- https://attack.mitre.org/techniques/T1499/

---
Source: https://www.netzilo.com/threats/transformers-get-imports-redos