The URLS regular expression in nltk/tokenize/casual.py, compiled into TweetTokenizer.WORD_RE and applied by TweetTokenizer.tokenize, contains a naked-domain branch whose domain-label prefix [a-z0-9]+(?:[.\-][a-z0-9]+)* is unbounded. Input consisting of many alternating label separators can be partitioned in exponentially many ways, and because the branch also requires a trailing top-level domain that such input never supplies, the engine explores those partitions before failing at each offset. A few kilobytes of input therefore consumes seconds to minutes of single-threaded CPU, and the HANG_RE substitution performed before matching does not collapse the pattern. TweetTokenizer is intended for tokenizing untrusted social-media text, so any service that applies it, or the module-level casual_tokenize, to submitted text can be stalled per request without authentication. Version 3.10.1 bounds the label repetition.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 1
- First seenCVSS 8.7NVD modified 2026-10-26 10:10
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 6
- https://github.com/nltk/nltk
- https://github.com/nltk/nltk/blob/3.9.4/nltk/tokenize/casual.py
- https://github.com/nltk/nltk/issues/3704
- https://github.com/nltk/nltk/releases/tag/v3.10.1
- https://www.vulncheck.com/advisories/nltk-tweettokenizer-url-pattern-backtracks-catastrophically-on-naked-domain-like-input
- https://github.com/nltk/nltk/issues/3704