GPU VulnDB

Database/AI/ML frameworks & serving

Transformers: attacker-supplied weight-decay regex patterns hang the training process (ReDoS)

CVSS 7.5CVE-2025-6921AI/ML frameworks & servingcurated

Impact

AdamWeightDecay's _do_use_weight_decay passes the include_in_weight_decay and exclude_from_weight_decay lists straight to re.search, so a pattern chosen to trigger catastrophic backtracking pins a core at 100% and the training step never returns. This matters only where those lists are not fixed by the operator - a shared training service that accepts user-supplied optimizer configuration. On a GPU cluster the practical cost is a job that holds its allocated GPUs while making no progress, burning reserved capacity until someone notices and kills it. No confidentiality or integrity impact; the record establishes availability only, and the NVD network vector overstates reach for the common case where configs come from trusted code.

Who can reach it

Anyone who can control the optimizer's weight-decay pattern lists - in practice a tenant submitting training configuration to a shared training service. Not reachable at all when those lists are hardcoded by the operator.

What to do

Upgrade the transformers library to 4.53.0 or later in the training image and restart affected jobs or the training service; no node maintenance is involved. Where an upgrade is not yet possible, validate or allowlist user-supplied regex patterns and enforce per-job wall-clock limits so a hung step releases its GPUs.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.