Vulnerabilities

NLTK's PorterStemmer.stem() in versions up to and including 3.10.2 contains an inefficient-algorithmic-complexity flaw (CWE-407): the _is_consonant() helper walks backward over the entire run of trailing 'y' characters on every call, and _measure() invokes it for each stem position, producing O(n^2) behavior on a single token. An attacker who can submit one untrusted token of roughly 20-50 KB — e.g., a long run of the letter 'y' followed by a matching suffix such as 'ness' — can pin a CPU core for seconds to minutes. The impact is purely to availability: repeated or concurrent malicious tokens can exhaust CPU and stall or degrade a service, with no confidentiality or integrity impact. Any application or service running NLTK ≤ 3.10.2 that applies PorterStemmer to attacker-controlled text is affected, while offline or research use on trusted corpora is largely unaffected. Exploitation has not been observed in the wild (not in CISA KEV, EPSS ~0.4%), but a public security advisory with PoC reference (GHSA-ww6m-cw3f-q94g) exists and a fixed release, 3.10.3, is available.

Do: Upgrade to NLTK 3.10.3 or later, which fixes the quadratic behavior in PorterStemmer. As interim mitigation, cap the length of untrusted tokens before stemming (e.g., reject or truncate single tokens above a few KB) or apply timeouts and rate limits around stemming of user input. Audit whether your services pass attacker-controlled text to PorterStemmer.stem() or related stemming entry points, and prioritize those for patching.

NLTK (Natural Language Toolkit) contains a regular expression denial-of-service flaw (ReDoS, CWE-1333) in the nltk.text module: Text.findall() and TokenSearcher.findall() pass caller-supplied regular expressions to Python's re engine with no validation or timeout, after preprocessing that does not prevent catastrophic backtracking. When an application feeds an attacker-controlled pattern (for example, a nested-quantifier pattern that fails to match) into these methods against a crafted token string, re.findall can backtrack indefinitely and the call never returns. An unauthenticated attacker who can influence the regex or the searched tokens can saturate the CPU of the Python process with a single request, denying service to all other users of that process; confidentiality and integrity are unaffected. Affected parties are Python applications installed via pip that expose these nltk.text search functions to external input; NLTK is extremely widely installed, but only services that pass untrusted regular expressions to findall() are actually exploitable. The issue was resolved upstream in commit d8e4753 and no in-the-wild exploitation is known: it is not in CISA KEV, no public PoC is known, EPSS estimates roughly a 0.5% probability of exploitation within 30 days (40th percentile), and CVSS 4.0 scores it 8.7 High.

Do: Update NLTK to a release that includes fix commit d8e4753; the advisory does not name a version number, so verify the fix is present in your installed version rather than assuming any current release is safe. Until then, do not pass user-controlled regular expressions to Text.findall()/TokenSearcher.findall(); if unavoidable, validate and length-limit patterns (avoid nested quantifiers) and run matching under a timeout, for example in a worker thread with a deadline. Audit your codebase and dependencies for calls to these methods with external input to determine whether you are exposed at all.

NLTK, a widely used Python natural-language processing library, contains an unsafe deserialization flaw (CWE-502) in TransitionParser.parse(), which loads parser model files via pickle through an unrestricted unpickler. When an application calls parse() with a model file whose contents or location an attacker controls, embedded pickle gadget chains (e.g., os.system or subprocess.Popen) execute arbitrary Python code with the privileges of the process invoking NLTK. Although NLTK ships a RestrictedUnpickler designed for safe loading, no production call site - in transitionparser.py or the chart parser modules - passes restricted=True, so the flaw exists in all versions that include the TransitionParser module and is unpatched as of the available data. Researchers, students, data scientists, and automated ML pipelines that use NLTK transition-based dependency parsing with model files from untrusted sources are most at risk. No public proof of concept, CISA KEV listing, or in-the-wild exploitation is known, and EPSS puts the 30-day exploitation probability at about 0.3%.

Do: Until a patched release is announced, avoid loading TransitionParser (and chart parser) model files from untrusted or user-controlled sources, and audit code for calls to TransitionParser().parse() or the affected chartparser pickle_load call sites. Monitor the NLTK project for a release that enables restricted=True unpickling in production paths and upgrade promptly when available. As interim mitigation, run NLTK-dependent jobs under least-privilege accounts and restrict where model files can be written from.

NLTK before 3.10.3 contains a remote code execution vulnerability in AllowlistUnpickler that validates only the pickle module string and not the global name, allowing attackers to resolve dotted names by attribute traversal to callables outside the allowlisted namespace. Attackers can craft untrusted transition-parser models that execute arbitrary commands when TransitionParser.parse loads the model through allowlisted_pickle_load.