CVE-2026-12372
published 2026-08-09CVE-2026-12372: 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()`…
PriorityP418low3.7CVSS 3.0
AVNACHPRNUINSUCLINAN
EPSS
0.26%
17.6th percentile
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
17 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| ansible-automation-platform-25 | lightspeed-chatbot-rhel8 | — | — |
| exploit-intelligence-tech-preview | vulnerability-analysis-rhel9 | — | — |
| lightspeed-core | lightspeed-stack-rhel9 | — | — |
| lightspeed-core | rag-tool-cpu-rhel9 | — | — |
| lightspeed-core | rag-tool-cuda-12.9-rhel9 | — | — |
| nltk | nltk | — | — |
| nltk | nltk | >= 0 < 3.10.0 | 3.10.0 |
| nltk | nltk_nltk | unspecified – latest | — |
| openshift-lightspeed-tech-preview | lightspeed-rag-tool-rhel9 | — | — |
| openshift-lightspeed | lightspeed-ocp-rag-rhel9 | — | — |
| openshift-lightspeed | lightspeed-service-api-rhel9 | — | — |
| rhoai | odh-llama-stack-core-rhel9 | — | — |
| rhoai | odh-pipeline-runtime-pytorch-llmcompressor-cuda-py312-rhel9 | — | — |
| rhoai | odh-ta-lmes-job-rhel9 | — | — |
| rhoai | odh-trustyai-garak-lls-provider-dsp-rhel9 | — | — |
| rhoai | odh-trustyai-nemo-guardrails-server-rhel9 | — | — |
| rhoai | odh-workbench-jupyter-pytorch-llmcompressor-cuda-py312-rhel9 | — | — |
CVSS provenance
nvdv3.03.7LOWCVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
vendor_redhat3.7LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk versions 3.9.4 and the current develop branch.
ghsa_unreviewed·2026-08-10
CVE-2026-12372 [LOW] CWE-918 A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk versions 3.9.4 and the current develop branch.
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 S
GHSA
NLTK network URL validation permits SSRF to RFC 6598 shared-address-space hosts
ghsa·2026-08-10
CVE-2026-12372 [LOW] CWE-918 NLTK network URL validation permits SSRF to RFC 6598 shared-address-space hosts
NLTK network URL validation permits SSRF to RFC 6598 shared-address-space hosts
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-publ
VulDB
NLTK up to 3.9.4 nltk.pathsec.validate_network_url server-side request forgery
vuldb·2026-08-10·CVSS 3.7
CVE-2026-12372 [LOW] NLTK up to 3.9.4 nltk.pathsec.validate_network_url server-side request forgery
A vulnerability was found in NLTK up to 3.9.4. It has been classified as problematic. Affected is the function nltk.pathsec.validate_network_url. The manipulation leads to server-side request forgery.
This vulnerability is uniquely identified as CVE-2026-12372. The attack is possible to be carried out remotely. No exploit exists.
Red Hat
nltk: NLTK: Server-Side Request Forgery via improper network URL validation
vendor_redhat·2026-08-09·CVSS 3.7
CVE-2026-12372 [LOW] CWE-918 nltk: NLTK: Server-Side Request Forgery via improper network URL validation
nltk: NLTK: Server-Side Request Forgery via improper network URL validation
A flaw was found in NLTK. A Server-Side Request Forgery (SSRF) vulnerability allows an attacker to influence a URL passed to NLTK's network-loading helpers. This occurs because the `nltk.pathsec.validate_network_url()` function fails to properly identify and reject IP addresses within the RFC 6598 shared address space (100.64.0.0/10). This could lead to the exposure of non-public infrastructure reachable from the application host, resulting in confidentiality exposure.
Package: exploit-intelligence-tech-preview/vulnerability-analysis-rhel9 (Exploit Intelligence) - Out of support scope
Package: lightspeed-core/lightspeed-stack-rhel9 (Lightspeed Core) - Fix deferred
Package: lightspeed-core/rag-tool-cpu-rhel9 (Li
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2026-12372 python-nltk: NLTK: Server-Side Request Forgery via improper network URL validation [fedora-all]
bugzilla·2026-08-10·CVSS 3.7
CVE-2026-12372 [LOW] CVE-2026-12372 python-nltk: NLTK: Server-Side Request Forgery via improper network URL validation [fedora-all]
CVE-2026-12372 python-nltk: NLTK: Server-Side Request Forgery via improper network URL validation [fedora-all]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
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_
Bugzilla
CVE-2026-12372 python-nltk: NLTK: Server-Side Request Forgery via improper network URL validation [epel-all]
bugzilla·2026-08-10·CVSS 3.7
CVE-2026-12372 [LOW] CVE-2026-12372 python-nltk: NLTK: Server-Side Request Forgery via improper network URL validation [epel-all]
CVE-2026-12372 python-nltk: NLTK: Server-Side Request Forgery via improper network URL validation [epel-all]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
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_pr
Bugzilla
CVE-2026-12372 nltk: NLTK: Server-Side Request Forgery via improper network URL validation
bugzilla·2026-08-09·CVSS 3.7
CVE-2026-12372 [LOW] CVE-2026-12372 nltk: NLTK: Server-Side Request Forgery via improper network URL validation
CVE-2026-12372 nltk: NLTK: Server-Side Request Forgery via improper network URL validation
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 exposi
2026-08-09
Published