The WekaClassifier component in NLTK improperly handles caller-controlled model file paths by passing them directly to the weka Java VM without validating them against NLTK's path security enforcement. This allows an attacker to specify arbitrary file paths for model saving and loading, enabling arbitrary file writes and reads outside the intended data root directories. This vulnerability bypasses the pathsec containment measures introduced in a prior advisory (CVE-2026-81726) and affects NLTK versions prior to 3.10.4.
NLTK versions up to 3.10.3 have a path traversal vulnerability in the WekaClassifier component. This flaw allows attackers who control the model filename or model argument to bypass path containment checks and cause the Weka JVM to write or probe files outside of permitted directories.
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 versions up to and including 3.10.3 have a path traversal vulnerability in certain model-artifact APIs. This flaw allows attackers to bypass path security enforcement and perform unauthorized read or write operations on files outside the intended sandbox. The affected components include TransitionParser, AveragedPerceptron, PerceptronTagger, and maxent parameter APIs when pathsec is enabled.
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.
NLTK 3.9.4 through 3.10.2 contains a path traversal vulnerability in CrubadanCorpusReader. _load_lang_ngrams joins the corpus root with crubadan_code, the column-0 value read from the corpus table.txt mapping file, and opens the result with the builtin open() rather than the pathsec-validated opener, so os.path.join discards the root when that value is absolute and the read escapes the corpus directory without the containment check nltk.pathsec applies when ENFORCE is set. An attacker who controls a corpus package can disclose file contents outside the corpus root through lang_freq, limited to paths ending in -3grams.txt whose contents parse as token count lines.
The NLTK FramenetCorpusReader.frame() method contains a path traversal vulnerability that allows an attacker to read arbitrary XML files outside the intended corpus root directory. This occurs because the method constructs file paths from user-supplied frame names without proper containment checks and bypasses the nltk.pathsec sandbox enforcement. The vulnerability affects versions prior to 3.10.0 and certain 1.0.8 versions. A proof-of-concept demonstrates that an attacker can read sensitive XML files outside the corpus root despite strict sandbox enforcement. The vulnerability has a CVSS score of 7.5 (high severity) and a patch is available.
A path traversal vulnerability in the Natural Language Toolkit (NLTK) component NKJPCorpusReader allows an attacker to read arbitrary files outside the intended corpus root directory. This occurs because NKJPCorpusReader constructs file paths via unsafe string concatenation and uses the builtin open() function directly, bypassing NLTK's pathsec sandbox protections even when strict enforcement mode (ENFORCE=True) is enabled. The vulnerability was confirmed in NLTK version 3.9.4 and the current development branch. An attacker controlling the fileids argument can exploit this to read sensitive files outside the corpus root.
CVE-2026-12061 is a Regular Expression Denial of Service (ReDoS) vulnerability in the Natural Language Toolkit (NLTK) ReviewsCorpusReader component used by the gptline product. The vulnerability arises from an unbounded greedy regex pattern in the FEATURES regex, which extracts feature annotations from review lines. When processing a long bracket-less line, the regex causes quadratic backtracking, leading to excessive CPU consumption and hanging the processing thread. This can be exploited by an attacker supplying a crafted review line to cause denial of service without requiring authentication or privileges. A patch is available that bounds the regex to prevent the quadratic behavior while preserving correct extraction on legitimate input.
NLTK's pathsec module includes an SSRF filter intended to block access to loopback, private, link-local, and multicast IP ranges. However, this filter can be bypassed via DNS rebinding, where the hostname resolves to a public IP during validation but resolves to an internal or loopback IP at connection time. This bypass defeats the strict ENFORCE mode, allowing unauthorized access to internal services. The vulnerability is identified as CVE-2026-12075 and has a high severity score of 8.6. A patch is available to address this issue.
NLTK versions prior to 3.9.3 contain an eval injection vulnerability in the nltk.collocations module. This flaw allows attackers controlling command-line arguments to execute arbitrary Python code by passing unsanitized input to eval() in the __main__ block of collocations.py. The vulnerability arises because command-line arguments are used as suffixes of BigramAssocMeasures without validation, enabling escape from intended attribute lookups and execution of OS commands via the os module. A patch is available to address this issue.
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.
A vulnerability in nltk's WordNet Browser HTTP server (up to version 3.9.3) allows unauthenticated remote shutdown via a specific GET request, causing denial of service. The server listens on all interfaces and lacks authentication for this critical function. This issue impacts service availability by terminating the server process immediately.
A vulnerability in the `filestring()` function of the `nltk.util` module in nltk version 3.9.2 allows arbitrary file read due to improper validation of input paths. The function directly opens files specified by user input without sanitization, enabling attackers to access sensitive system files by providing absolute paths or traversal paths. This vulnerability can be exploited locally or remotely, particularly in scenarios where the function is used in web APIs or other interfaces that accept user-supplied input.
NLTK versions <=3.9.2 are vulnerable to arbitrary code execution due to improper input validation in the StanfordSegmenter module. The module dynamically loads external Java .jar files without verification or sandboxing. An attacker can supply or replace the JAR file, enabling the execution of arbitrary Java bytecode at import time. This vulnerability can be exploited through methods such as model poisoning, MITM attacks, or dependency poisoning, leading to remote code execution. The issue arises from the direct execution of the JAR file via subprocess with unvalidated classpath input, allowing malicious classes to execute when loaded by the JVM.
A vulnerability in NLTK versions up to and including 3.9.2 allows arbitrary file read via path traversal in multiple CorpusReader classes, including WordListCorpusReader, TaggedCorpusReader, and BracketParseCorpusReader. These classes fail to properly sanitize or validate file paths, enabling attackers to traverse directories and access sensitive files on the server. This issue is particularly critical in scenarios where user-controlled file inputs are processed, such as in machine learning APIs, chatbots, or NLP pipelines. Exploitation of this vulnerability can lead to unauthorized access to sensitive files, including system files, SSH private keys, and API tokens, and may potentially escalate to remote code execution when combined with other vulnerabilities.
NLTK through 3.8.1 allows remote code execution if untrusted packages have pickled Python code, and the integrated data package download functionality is used. This affects, for example, averaged_perceptron_tagger and punkt.