CVE-2025-6921

What it actually does

CVE-2025-6921 is a Regular Expression Denial of Service vulnerability in the Hugging Face transformers library before version 4.53.0, specifically in the AdamWeightDecay optimizer path. The affected _do_use_weight_decay method evaluates user-controlled entries from include_in_weight_decay and exclude_from_weight_decay using Python re.search. If an attacker can supply a pathological regular expression with nested or ambiguous quantifiers, the regex engine can enter catastrophic backtracking while matching parameter names. This can pin a CPU core at 100%, stall model training or inference workflows that instantiate or configure AdamWeightDecay, and cause application-level denial of service. The flaw does not directly provide code execution, privilege escalation, or data disclosure, but it can make ML services or jobs unavailable.

Why it matters to the business

Organizations using vulnerable versions of huggingface/transformers in ML training, fine-tuning, experimentation platforms, model-serving pipelines, or user-configurable AI workflows may experience job hangs, degraded service responsiveness, increased compute cost, failed training runs, and interruption of AI-enabled business processes. The risk is highest where untrusted users, notebooks, APIs, plugins, or configuration files can control optimizer settings. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at the time of assessment, so broad opportunistic exploitation is less likely; however, exposure in shared ML platforms can still create practical denial-of-service risk.

How an attack unfolds

An attacker first needs a path to influence the AdamWeightDecay optimizer configuration, especially the include_in_weight_decay or exclude_from_weight_decay lists. This may occur through a hosted ML training service, user-submitted training scripts, model configuration ingestion, experiment tracking integrations, notebooks, CI/CD model pipelines, or any application that accepts optimizer parameters from less-trusted users. The attacker submits a crafted regular expression designed to cause catastrophic backtracking when re.search evaluates it against model parameter names. When the vulnerable transformers code initializes or evaluates weight decay behavior, _do_use_weight_decay repeatedly applies the attacker-controlled pattern. The Python process consumes excessive CPU and may stop making progress, causing the ML task, API worker, or pipeline stage to hang until killed, timed out, or restarted.

How to fix it

Upgrade huggingface/transformers to version 4.53.0 or later. For source-based deployments, ensure the code includes the upstream fixes represented by commits 47c34fba5c303576560cb29767efb452ff12b8be and 67ddc82fbc7e52c6f42a395b4a6d278c55b77a39. Rebuild and redeploy containers, notebooks, training images, model-serving images, and CI/CD environments that vendor or pin transformers. If immediate upgrade is not possible, prevent untrusted users from supplying include_in_weight_decay or exclude_from_weight_decay patterns, replace regex matching with exact-name or allowlisted matching where feasible, validate and reject high-risk regex constructs such as nested quantifiers, enforce job CPU/time limits, and isolate user-submitted ML workloads in resource-constrained sandboxes.

How to confirm the fix worked

Confirm that all runtime environments report transformers version 4.53.0 or later, for example with python -c "import transformers; print(transformers.__version__)". Review dependency lockfiles, container images, notebook kernels, build artifacts, and vendored source copies for older transformers versions. If validating from source, confirm the deployed code contains the fixed _do_use_weight_decay behavior from the referenced commits. Perform a controlled regression test by attempting to configure AdamWeightDecay with a known pathological regex in a non-production sandbox and verifying the process rejects, safely handles, or times out rather than consuming sustained CPU. Also verify that user-facing configuration interfaces no longer allow untrusted regex input or are protected by validation and resource limits.

Typical attack path

1. Identify an application, notebook service, training platform, or ML pipeline that uses huggingface/transformers before 4.53.0.
2. Find an input path that allows control over AdamWeightDecay optimizer settings or model training configuration.
3. Place a catastrophic-backtracking regular expression in include_in_weight_decay or exclude_from_weight_decay.
4. Trigger model initialization, training, fine-tuning, or another code path that calls _do_use_weight_decay.
5. Cause re.search to consume excessive CPU while evaluating the malicious regex against parameter names.
6. Maintain or repeat submissions to keep workers, jobs, or services unavailable.

How to detect it

Look for evidence of denial-of-service behavior rather than traditional malware artifacts. Relevant sources include application logs from ML services, notebook platforms, training orchestration logs, CI/CD job logs, Kubernetes events, container runtime metrics, process accounting, endpoint telemetry, and cloud workload monitoring. Investigate Python processes running transformers workloads that show sustained high CPU with little or no progress, repeated job timeouts during optimizer setup or training startup, worker restarts, or orchestrator kills due to liveness/readiness failures. Review submitted training configurations, notebook cells, API request bodies, experiment metadata, and pipeline parameters for suspicious values in include_in_weight_decay or exclude_from_weight_decay, especially regexes containing nested quantifiers or broad wildcards. In forensic review, capture stack traces or profiler output from hung workers and look for execution in transformers optimization code, _do_use_weight_decay, and Python re.search. Correlate suspicious regex submissions with subsequent CPU spikes, job hangs, 5xx responses, container restarts, or manual job terminations.

• include_in_weight_decay
• exclude_from_weight_decay
• AdamWeightDecay
• _do_use_weight_decay
• re.search
• transformers.optimization
• catastrophic backtracking
• CPU time limit exceeded
• Worker timeout
• Job timed out
• Killed process
• Liveness probe failed
• Readiness probe failed
• Back-off restarting failed container
• OOMKilled
• (.*)+
• (.+)+
• (a+)+
• ([A-Za-z]+)*
• (\w+)*

What your security team should do

• Inventory all applications, containers, notebooks, ML pipelines, and training images that include huggingface/transformers, prioritizing shared or externally reachable ML platforms.
• Upgrade transformers to 4.53.0 or later and rebuild all dependent artifacts rather than only changing source manifests.
• Search code and configuration repositories for use of AdamWeightDecay, include_in_weight_decay, and exclude_from_weight_decay to identify reachable attack surfaces.
• Restrict optimizer configuration inputs from untrusted users; prefer allowlists or exact string matching over arbitrary regular expressions.
• Apply CPU, memory, and wall-clock time limits to ML jobs and API workers that process user-submitted training configuration.
• Add monitoring for sustained 100% CPU utilization, long-running Python training workers, and repeated job timeouts associated with optimizer initialization.
• Because this is not currently KEV-listed and has low EPSS, prioritize remediation based on exposure: urgent for multi-user or public ML services, routine for isolated internal-only training environments.