Skip to content

GHSA-rrv8-h7p8-rx55 CVE-2026-80205 PYSEC-2026-3750

NLTK: ReDoS in nltk.text.Text.findall() via unvalidated user-supplied regular expressions

High PyPI
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.65%
Chance of exploitation in the next 30 days. Higher than 51.21% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-1333 Inefficient Regular Expression Complexity
Fix
3.10.0
Upgrade nltk to this version or later

Description

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:

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

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

Affected versions

PyPI

PackageVulnerableFixed in
nltk
< 3.10.0
3.10.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

nltk PyPI → 3.10.0

pip
pip install --upgrade "nltk>=3.10.0"
poetry
poetry add "nltk>=3.10.0"
uv
uv add "nltk>=3.10.0"

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-1333: Inefficient Regular Expression Complexity

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

How to prevent it
  • Architecture and Design: Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
  • System Configuration: Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
  • Implementation: Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
  • Implementation: Limit the length of the input that the regular expression will process.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-j456-xh4h-cpf2
NLTK: WekaClassifier passes an unvalidated caller-controlled model path to the weka JVM, bypassing nltk.pathsec containment
High Also affects nltk
GHSA-ff5c-cp5c-9wjf
NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars
Medium Also affects nltk
GHSA-f794-5jv7-7672
NLTK: Downloader.download follows hardlinks and overwrites outside-root files
High Also affects nltk
GHSA-8mgp-746c-j5xp
NLTK: Model-artifact APIs bypass pathsec and touch files outside allowed roots
High Also affects nltk
GHSA-8mpw-7fpc-4gqj
NLTK: Pl196xCorpusReader has quadratic ReDoS on malformed TEI blocks
Low Also affects nltk
GHSA-cw6x-m8jw-qmrh
NLTK: Uncontrolled recursion in nltk.featstruct.FeatStructReader causes unhandled RecursionError (DoS) via deeply nested feature-structure input
Medium Also affects nltk
GHSA-vp2x-qp44-57v7
NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`
Low Also affects nltk
GHSA-ww6m-cw3f-q94g
NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y'
High Also affects nltk
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor