NLTK before 3.10.3 contains a server-side request forgery vulnerability in nltk.pathsec.urlopen (and callers nltk.data.load, nltk.downloader.Downloader.index/download) when an HTTP proxy is configured. pathsec.urlopen validates the requested hostname locally, but proxy-handler inheritance disables the safe HTTP/HTTPS handlers so the actual fetch is performed by the proxy against a destination that is never re-validated. An attacker can supply a validated public URL that the proxy forwards to an internal loopback-only service, allowing disclosure of internal HTTP resources, loading of forged downloader indexes, and installation of attacker-chosen package content.
Fix
Patch, vendor advisory and mitigation references on NVD 2
- https://github.com/nltk/nltk/security/advisories/GHSA-6ww7-3frv-cqxh Exploit, Vendor Advisory
- https://github.com/nltk/nltk/security/advisories/GHSA-6ww7-3frv-cqxh Exploit, Vendor Advisory
Every line above is quoted from NVD, CISA, Microsoft, the vendor's own advisory or DISA; nothing is generated.
Change history 1
- First seenCVSS 8.7 · nltkNVD modified 2026-10-12 21:10
Affected (CPE criteria) 1
cpe:2.3:a:nltk:nltk:*:*:*:*:*:*:*:*
References 3
- https://github.com/nltk/nltk/security/advisories/GHSA-6ww7-3frv-cqxh Exploit, Vendor Advisory
- https://www.vulncheck.com/advisories/nltk-before-ssrf-protection-bypass-via-proxy Third Party Advisory
- https://github.com/nltk/nltk/security/advisories/GHSA-6ww7-3frv-cqxh Exploit, Vendor Advisory