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.

A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk versions 3.9.4 and the current develop branch. The `nltk.pathsec.validate_network_url()` function, intended to prevent SSRF by rejecting internal network addresses, fails to reject IPs in the RFC 6598 shared address space (`100.64.0.0/10`). This occurs because Python's `ipaddress` module does not classify such addresses as `is_private` or `is_global`, and the current guard only checks `is_private` and a few explicit categories. An attacker who can influence a URL passed to NLTK's network-loading helpers can exploit this vulnerability to make a strict-mode application send requests to shared-address-space hosts, potentially exposing non-public infrastructure reachable from the application host. The impact is limited to SSRF-style confidentiality exposure, with no code execution claimed.

A vulnerability in `nltk.downloader` in nltk/nltk versions <= 3.9.4 allows for cross-package resource and model poisoning. The downloader extracts package archives into shared namespaces such as `corpora/` and `taggers/` instead of package-isolated roots, and validates package integrity only after the archive has been written and extracted. This design flaw enables one package to overwrite another package's trusted resources within the same namespace, making the changes immediately active through ordinary NLTK APIs. This issue persists across fresh interpreter restarts and can affect downstream workflows, including machine learning pipelines and reproducibility-sensitive environments.

NLTK (Natural Language Toolkit) before version 3.9.3 contains an eval injection vulnerability in the nltk.collocations module that allows an attacker who controls command-line arguments to execute arbitrary Python code. When collocations.py is invoked directly, the __main__ block passes command-line arguments directly to eval() as suffixes of BigramAssocMeasures without allowlist validation or sanitization, enabling an attacker to supply a Python expression that escapes the intended attribute lookup and executes arbitrary code including OS commands via the os module.

In nltk/nltk versions 3.9.3 and earlier, five Stanford interface classes (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, and StanfordNeuralDependencyParser) are vulnerable to untrusted JAR code execution. These classes accept user-controllable JAR paths and execute them via the `java()` function, which invokes `subprocess.Popen()` without integrity verification. This vulnerability is identical to CVE-2026-0848, which was fixed for StanfordSegmenter by adding SHA256 verification. However, the fix was not applied to these additional classes, leaving them susceptible to arbitrary code execution when loading untrusted JAR files.

NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK's SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.