CVE-2026-80205: NLTK before 3.10.0 ReDoS via Text.findall() unvalidated regex
Summary NLTK's Text.findall() and TokenSearcher.findall() methods accept user-supplied regular expressions and pass them to the Python re engine without timeout or validation, enabling catastrophic backtracking (ReDoS). This issue is isolated to the nltk.text module and was resolved in a prior commit.
Affected Code nltk/text.py — TokenSearcher.findall() (line 255) / Text.findall() (line 620)
TokenSearcher.init builds an internal string by wrapping each token in angle brackets. The findall() method preprocesses the caller-supplied regexp and runs it directly against this string with no timeout:
python def findall(self, regexp): # Preprocessing does NOT prevent catastrophic backtracking regexp = re.sub(r"\s", "", regexp) regexp = re.sub(r"<", "(?:<(?:", regexp) regexp = re.sub(r">", ")>)", regexp) regexp = re.sub(r"(?<!\\)\.", "[^>]", regexp)
# User-controlled regexp executed with no timeout hits = re.findall(regexp, self.raw) The preprocessing transforms < and > angle-bracket syntax but does not inspect or reject catastrophically backtracking patterns.
Proof of Concept python import nltk import time
Token of 25 'a' characters produces self.raw = "<aaaaaaaaaaaaaaaaaaaaaaaa!>" The trailing '!' ensures no match, forcing full backtracking. text = nltk.Text(["a" 25 + "!"])
Pattern after transformation: < → (?:<(?: → )>) Becomes: (?:<(?:((a+)+)b)>) re.findall runs this against "<aaaaaaaaaaaaaaaaaaaaaaaa!>" — hangs.
start = time.time() text.findall(r"<((a+)+)b>") # Never returns
Impact Applications that expose Text.findall() to external input are vulnerable to a denial of service. An unauthenticated attacker can cause indefinite CPU saturation with one request, denying service to all other users of the Python process.
Remediation This vulnerability was patched in commit d8e4753. Users should update to the patched version.
Credit Tool: Kira by Offgrid Security
Other sources
NLTK versions before 3.10.0 contain a regular expression denial of service vulnerability in Text.findall() and TokenSearcher.findall() methods that accept user-supplied regular expressions without validation or timeout. Attackers can supply crafted regex patterns that cause catastrophic backtracking, resulting in indefinite CPU saturation and denial of service to all users of the Python process.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/nltkto a version that resolves this vulnerability.Fixed in 3.10.0 - Upgrade
Upgrade
nltkto a version that resolves this vulnerability.Fixed in 3.10.0Patch d8e4753 - Compensating control
If you must accept user-supplied regexes for nltk.text Text.findall() / TokenSearcher.findall(), apply a timeout/validation mechanism before passing the pattern to Python's re.findall, since the methods run the regexp directly with no timeout.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using NLTK versions before 3.10.0 are exposed when they pass attacker-controlled regular-expression patterns to Text.findall() or TokenSearcher.findall(). The impact is denial of service against the Python process running the affected code.
Does exploitation require authentication or user interaction?
No. The provided vector indicates network-reachable exploitation with low attack complexity, no privileges, and no user interaction, provided an attacker can supply a regex pattern to an affected method.
What is the immediate mitigation if upgrading is not possible?
Do not allow untrusted users to provide arbitrary regular expressions to Text.findall() or TokenSearcher.findall(). Restrict accepted patterns or otherwise validate them before calling these methods, since the affected versions have no regex validation or timeout.
How can I determine whether my deployment is affected?
Check whether the application uses NLTK before version 3.10.0 and whether it calls Text.findall() or TokenSearcher.findall() with regex patterns influenced by external input. Affected executions may show sustained or indefinite CPU consumption in the Python process when processing crafted patterns.