Bug 2513003 (CVE-2026-12372)

Summary: CVE-2026-12372 nltk: NLTK: Server-Side Request Forgery via improper network URL validation
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: anpicker, dschmidt, ebourniv, hasun, jfula, jlanda, jowilson, kshier, lgallett, nyancey, ometelka, ptisnovs, sbunciak, simaishi, stcannon, syedriko, teagle, xdharmai, yguenane
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2513061, 2513062    
Bug Blocks:    

Description OSIDB Bzimport 2026-08-09 23:01:20 UTC 
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.