CVE-2025-1194

What it actually does

This is a Regular Expression Denial of Service issue in the GPT-NeoX-Japanese tokenizer implementation in huggingface/transformers. In affected code, the SubWordJapaneseTokenizer in tokenization_gpt_neox_japanese.py applies a regular expression whose matching behavior can become exponentially expensive for specially crafted input. When an application tokenizes attacker-controlled text with the GPT-NeoX-Japanese model/tokenizer, a single request can consume excessive CPU time, block a worker thread or process, and degrade or interrupt service availability. The vulnerability does not directly provide code execution, privilege escalation, or data disclosure; the primary impact is availability loss.

Why it matters to the business

Organizations using affected versions of huggingface/transformers for GPT-NeoX-Japanese text processing, inference APIs, chatbots, document-processing pipelines, or ML services could experience slow responses, request timeouts, increased infrastructure cost, autoscaling spikes, or temporary service outages if attackers or abusive users submit crafted input repeatedly. The CVSS score is moderate and EPSS is low, with no CISA KEV listing or known ransomware association, so broad exploitation pressure appears limited; however, internet-facing ML inference or text-processing endpoints are more exposed because user-supplied text is commonly passed directly into tokenizers.

How an attack unfolds

An attacker first identifies an application path that accepts free-form text and uses the GPT-NeoX-Japanese tokenizer from an affected transformers version. They then submit a carefully shaped input that triggers catastrophic backtracking in the vulnerable regular expression used during tokenization. The application spends excessive CPU cycles trying to process the input before model inference even begins. If the attacker repeats the request, sends it concurrently, or targets multiple workers, the service can become saturated, causing legitimate requests to queue, timeout, or fail. Because this flaw is in preprocessing logic, exploitation may occur through ordinary API requests, chat prompts, batch-uploaded text, or any workflow that tokenizes untrusted content with the affected tokenizer.

How to fix it

Upgrade huggingface/transformers to a version that includes the upstream fix, or pin the dependency to a commit at or after 92c5ca9dd70de3ade2af2eb835c96215cc50e815. If using the Git source directly, ensure the deployed revision includes commit 92c5ca9dd70de3ade2af2eb835c96215cc50e815. If immediate upgrade is not possible, reduce exposure by rejecting or truncating unusually long tokenizer inputs, enforcing per-request CPU/time limits, applying request rate limits, isolating tokenizer workloads from core application workers, and disabling or avoiding GPT-NeoX-Japanese tokenization for untrusted input until patched. Also update lockfiles, container images, model-serving images, notebooks, batch workers, and inference services that vendor or bundle transformers.

How to confirm the fix worked

Confirm the installed transformers source contains the fixed implementation by checking the deployed package or Git revision for commit 92c5ca9dd70de3ade2af2eb835c96215cc50e815 or a later release containing it. Inventory runtime environments with package managers such as pip, poetry, conda, container SBOM tooling, or source checkout metadata to ensure affected transformers builds are no longer deployed. Validate that applications accepting untrusted text enforce maximum input length, request timeout, and rate-limit controls. In a controlled non-production environment, run regression tests against GPT-NeoX-Japanese tokenization using representative long and malformed inputs and confirm tokenization completes within expected latency and CPU bounds without worker exhaustion.

Typical attack path

1. Find a public or reachable application feature that accepts arbitrary text, prompts, uploaded documents, or batch NLP input.
2. Determine or infer that the backend uses huggingface/transformers with the GPT-NeoX-Japanese tokenizer.
3. Send specially crafted text designed to trigger worst-case regular-expression backtracking during tokenization.
4. Observe delayed responses, request timeouts, or elevated CPU utilization as confirmation of impact.
5. Repeat or parallelize the requests to exhaust worker capacity and degrade service availability.

How to detect it

Detecting prior exploitation is difficult because no public, stable payload indicator is provided and attacks may look like ordinary text submissions followed by abnormal processing time. Review application, API gateway, WAF, load balancer, and model-serving logs for requests to text-processing or inference endpoints that correlate with sudden CPU spikes, worker starvation, request timeouts, or elevated 5xx/504 responses. Focus on services using GPT-NeoX-Japanese tokenization and inspect request metadata around the start of high-CPU events: client IPs, user IDs where applicable, request sizes, repeated prompts, unusual Unicode-heavy or repetitive strings, and concurrent requests from the same source. Check APM traces and Python stack samples for execution time concentrated in transformers/models/gpt_neox_japanese/tokenization_gpt_neox_japanese.py or SubWordJapaneseTokenizer. Review container and host telemetry for python processes consuming sustained high CPU without corresponding model inference progress. Since no named threat actors, KEV exploitation, or ransomware use are reported, prioritize behavioral evidence over IOC-only matching.

What your security team should do

• Prioritize patching internet-facing or multi-tenant services that tokenize user-controlled text with GPT-NeoX-Japanese using huggingface/transformers.
• Upgrade or pin transformers to a build containing commit 92c5ca9dd70de3ade2af2eb835c96215cc50e815, and rebuild dependent containers or model-serving images.
• Add input-size limits, request timeouts, concurrency limits, and per-client rate limits around text-tokenization and inference endpoints.
• Monitor CPU saturation, request latency, timeout rates, and worker restarts for services that use transformers tokenizers.
• Search dependency inventories, SBOMs, lockfiles, notebooks, and ML pipeline images for affected transformers deployments, not just production web services.
• Because EPSS is low, exploit maturity is currently listed as none, and the issue is not in KEV, treat this as a targeted availability risk rather than an emergency across all assets; raise priority where untrusted users can submit text at scale.