Transformers get_imports ReDoS Exposure
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.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f9c1d7e-6b24-4a58-9e0d-7c41b8ad52f6
- Severity
- Medium
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.