NLTK network URL validation permits SSRF to RFC 6598 shared-address-space hosts
Low3.7CVE-2026-12372 · Published Aug 10, 2026 · updated Oct 2, 2026
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.
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| nltk PyPI | < 3.10.0 | 3.10.0 |
Details and references
- CVSS 3.0
- CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-918
- Also known as
- CVE-2026-12372, PYSEC-2026-3955
More NLTK advisories
All NLTK| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Aug 13 | nltk: Arbitrary File Read via Path Traversal in nltk.data.load() through Percent-Encoded Sequences | High7.5 | 3.10.0 |
| Aug 9 | NLTK: server-side request forgery | Low3.7 | No fix yet |
| Aug 7 | NLTK downloader allows cross-package resource and model poisoning | Medium5.3 | 3.10.0 |
| Aug 7 | A vulnerability in `nltk.downloader` in nltk/nltk versions <= 3.9.4 | Medium6.5 | 3.10.0 |
| Jul 31 | NLTK: server-side request forgery | High8.6 | 3.10.0 |
| Jul 31 | Natural Language Toolkit (NLTK): ReDoS in NLTK ReviewsCorpusReader FEATURES regex | High7.5 | 3.10.0 |