CVE-2026-12372
LowCVSS 3.7Exploitation Probability (EPSS)
Low risk17th percentile - higher than 17% of all known CVEs
Summary
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.
Risk Assessment
An attacker can exploit SSRF to send requests to internal resources in the shared address space, potentially exposing non-public services and data.
Recommendation
Update NLTK to a patched version or manually extend IP validation to include the 100.64.0.0/10 block. Restrict the ability to influence URLs passed to NLTK.
Other vulnerabilities in NLTK
See all- CVE-2026-79675Critical
NLTK before 3.10.3 fails to validate JVM options passed through the per-call options parameter in the java() function, allowing attackers to inject dangerous JVM flags. Attackers can supply malicious options like -agentpath, -javaagent, or @argfile to Stanford wrapper classes to achieve arbitrary code execution.
- CVE-2026-79657Critical
NLTK versions before 3.10.3 contain a remote code execution vulnerability in allowlisted pickle loaders that trust entire module namespaces instead of specific safe callables. Attackers can craft malicious pickle payloads invoking dangerous in-namespace functions like ReppTokenizer._execute and numpy.f2py.crackfortran.myeval through pickle REDUCE to execute arbitrary commands during model or tokenizer artifact loading.
- CVE-2026-78683Critical
NLTK before 3.10.0 contains an unsafe pickle deserialization vulnerability in TransitionParser.parse(). Deserialization uses default restricted=False, allowing arbitrary Python code execution when loading a crafted model file.
- CVE-2026-81727High
NLTK versions before 3.10.3 contain a filesystem containment bypass vulnerability in the Downloader.download and Downloader.incr_download methods that allows attackers to overwrite files outside the install root through pre-existing hardlinks. Attackers with write access to a shared downloader directory can create hardlinks pointing to outside-root files that are then overwritten during normal package extraction.
- CVE-2026-81726High
NLTK through 3.10.3 contains a path traversal vulnerability in model-artifact APIs that bypass pathsec enforcement by using raw file operations on caller-controlled paths. Attackers can read or write files outside allowed sandbox roots through TransitionParser, AveragedPerceptron, PerceptronTagger, and maxent parameter APIs when pathsec is enabled.
- CVE-2026-81725Low
NLTK before 3.10.3 has a regular expression denial of service vulnerability in Pl196xCorpusReader. Attackers can supply malformed TEI blocks causing quadratic CPU consumption.
- CVE-2026-81724Medium
NLTK before 3.10.3 contains an uncontrolled recursion vulnerability in nltk.featstruct.FeatStructReader that allows unauthenticated attackers to cause a denial of service by supplying deeply nested feature-structure input. Attackers can craft trivial payloads with nested brackets that exceed Python's recursion limit and raise an unhandled RecursionError, crashing applications that parse user-supplied feature structures or feature grammars.
- CVE-2026-81723Low
NLTK before 3.10.3 has a quadratic CPU exhaustion vulnerability in XMLCorpusView._read_xml_fragment(). Malformed XML files can cause severe CPU consumption and DoS.
- CVE-2026-81722High
NLTK PorterStemmer in versions <= 3.10.2 (fixed in 3.10.3) contains an inefficient-algorithmic-complexity denial of service in PorterStemmer.stem(). 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, causing O(n^2) behavior. A single ~20-50 KB untrusted token consisting of a long run of the letter 'y' followed by a matching suffix (e.g., 'ness') can pin a CPU core for seconds to minutes.
- CVE-2026-80206Medium
NLTK before 3.10.3 has a ReDoS vulnerability in the tgrep module. The _tgrep_node_action function compiles user-supplied regex patterns and executes them without validation, potentially causing catastrophic backtracking and blocking the Python process.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

