CVE-2026-78682: NLTK before 3.10.3 SSRF Protection Bypass via Proxy
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
NLTK (nltk.pathsec.urlopen)to a version that resolves this vulnerability.Fixed in 3.10.3 - Compensating control
If you must run a vulnerable NLTK version prior to 3.10.3, avoid configuring an HTTP proxy for calls that use nltk.pathsec.urlopen (and callers nltk.data.load, nltk.downloader.Downloader.index/download), since SSRF validation is bypassed when a proxy is configured.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using NLTK before 3.10.3 are exposed when an HTTP proxy is configured and NLTK performs requests through nltk.pathsec.urlopen or affected callers such as nltk.data.load and nltk.downloader.Downloader.index or download.
What does an attacker need to exploit the vulnerability?
An attacker needs to be able to supply a public URL that passes NLTK's local hostname validation. The configured proxy must then forward that request to an internal or loopback-only HTTP destination that is not re-validated by NLTK.
What could exploitation allow?
Exploitation can disclose internal HTTP resources. It can also allow forged downloader indexes to be loaded and attacker-chosen package content to be installed.