CVE-2025-6638

What it actually does

CVE-2025-6638 is a Regular Expression Denial of Service flaw in Hugging Face Transformers 4.52.4 affecting the MarianTokenizer remove_language_code() method. Crafted input containing malformed or pathological language-code-like patterns can trigger inefficient regular expression behavior, causing excessive CPU consumption during tokenization. The impact is denial of service rather than code execution: a process handling attacker-controlled text can become slow, unresponsive, or resource-starved.

Why it matters to the business

Services that expose MarianTokenizer-based machine translation or NLP processing to user-supplied input may experience degraded performance or outages when processing malicious text. This can affect customer-facing APIs, batch processing pipelines, inference workers, and applications that depend on timely model responses. EPSS is low and there is no known KEV listing or reported ransomware use, so this is not currently an internet-wide emergency, but it should still be remediated where untrusted text reaches affected tokenizer code.

How an attack unfolds

An attacker identifies an application or API that accepts arbitrary text and processes it with Hugging Face Transformers MarianTokenizer on an affected version. The attacker submits specially crafted strings that resemble malformed language-code patterns designed to exercise the vulnerable regular expression in remove_language_code(). When the application tokenizes the input, regex evaluation consumes disproportionate CPU time. Repeated requests or concurrent submissions can tie up worker threads or processes, increase queue latency, exhaust autoscaling capacity, and produce a denial-of-service condition. Exploitation does not require authentication if the vulnerable text-processing endpoint is publicly reachable and accepts unauthenticated input.

How to fix it

Upgrade Hugging Face Transformers to version 4.53.0 or later. For source-based deployments, ensure the fix corresponding to commit 47c34fba5c303576560cb29767efb452ff12b8be or a later release is present. Rebuild containers, serverless packages, model-serving images, notebooks, and dependency lockfiles so the patched library is actually deployed. If immediate upgrade is not possible, reduce exposure by limiting maximum input length, rejecting malformed language-code prefixes, applying request rate limits, enforcing CPU/time limits around tokenization, isolating inference workers, and placing queue/concurrency controls in front of text-processing endpoints. Review package metadata carefully because the supplied affected-product list includes unrelated Debian cacti entries; remediation should be based on actual use of Hugging Face Transformers MarianTokenizer in deployed code.

How to confirm the fix worked

Confirm installed versions with package manifests and runtime checks such as pip show transformers, poetry.lock, requirements files, container SBOMs, or direct inspection of transformers.__version__. The vulnerable version called out is 4.52.4; fixed deployments should run Transformers 4.53.0 or later, or include the fixed source commit. Validate by running regression tests against MarianTokenizer with normal and malformed language-code-like inputs and confirming tokenization completes within expected time limits. In production, confirm that rebuilt artifacts are deployed everywhere, old containers are no longer running, and monitoring shows no abnormal CPU spikes or request timeouts during tokenization.

Typical attack path

1. Find a service that performs Marian machine translation or uses MarianTokenizer from Hugging Face Transformers.
2. Confirm the service accepts user-controlled text that is passed into tokenization.
3. Submit crafted malformed language-code-like strings that trigger inefficient regex processing in remove_language_code().
4. Repeat or parallelize requests to keep CPU-bound tokenizer workers busy.
5. Cause elevated latency, request timeouts, worker exhaustion, failed inference jobs, or service unavailability.

How to detect it

Look for evidence of denial-of-service behavior around NLP or translation endpoints rather than classic malware artifacts. Useful sources include application access logs, API gateway logs, reverse proxy logs, model-serving logs, worker stderr/stdout, APM traces, container metrics, host CPU metrics, job queue telemetry, and autoscaling events. Investigate periods with sudden CPU saturation, long request durations, tokenizer or inference timeouts, worker restarts, or repeated requests containing unusual language-code-like prefixes or very long malformed text. Correlate high CPU in Python processes with requests routed to MarianTokenizer-backed translation or NLP functionality. Review stack traces, profiling samples, or crash dumps for repeated time spent in transformers.models.marian.tokenization_marian or remove_language_code. There are no known public threat actors or KEV exploitation campaigns associated with this vulnerability, so detection should focus on anomalous resource-consumption patterns and suspicious crafted input attempts.

• MarianTokenizer
• remove_language_code
• remove_language_code()
• transformers.models.marian.tokenization_marian
• tokenization_marian.py
• transformers==4.52.4
• huggingface/transformers 4.52.4
• CPU timeout during tokenization
• request timeout during tokenization
• worker timeout during tokenization

What your security team should do

• Inventory applications, model-serving endpoints, notebooks, pipelines, and containers that use Hugging Face Transformers, especially MarianTokenizer or Marian machine translation models.
• Prioritize patching externally reachable or multi-tenant services that tokenize untrusted text.
• Upgrade Transformers to 4.53.0 or later and rebuild all affected deployment artifacts and dependency lockfiles.
• Add input-size limits, request throttling, queue limits, and execution timeouts around text-processing endpoints as defense in depth.
• Monitor CPU saturation, inference latency, request timeouts, and worker restarts for services that process untrusted text.
• If patching is delayed, restrict public access to affected endpoints or require authentication and rate limiting until upgraded.
• Verify whether dependency scanners are incorrectly reporting unrelated cacti packages and tune vulnerability management records to the actual affected component.