Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
No advisories yet.
Mon, 10 Aug 2026 01:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Nltk
Nltk nltk/nltk |
|
| Vendors & Products |
Nltk
Nltk nltk/nltk |
Mon, 10 Aug 2026 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Sun, 09 Aug 2026 23:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Server-Side Request Forgery (SSRF) in nltk/nltk | |
| Weaknesses | CWE-918 | |
| References |
| |
| Metrics |
cvssV3_0
|
Status: PUBLISHED
Assigner: @huntr_ai
Published:
Updated: 2026-08-09T22:45:52.799Z
Reserved: 2026-06-16T06:05:39.765Z
Link: CVE-2026-12372
No data.
No data.
OpenCVE Enrichment
Updated: 2026-08-10T01:00:10Z
-
CWE-918
Server-Side Request Forgery (SSRF)