CVE-2026-78682: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-78682 is a Server-Side Request Forgery (SSRF) vulnerability in the Natural Language Toolkit (NLTK) Python library affecting all versions before 3.10.3. The flaw resides in nltk.pathsec.urlopen and its callers (nltk.data.load, nltk.downloader.Downloader.index, and nltk.downloader.Downloader.download) when an HTTP proxy is configured. It was published on August 25, 2026, with the underlying security advisory (GHSA-6ww7-3frv-cqxh) authored by researcher sondt99 and published August 11, 2026. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, NLTK Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery) and CWE-441 (Unintended Proxy or Intermediary). pathsec.urlopen() performs hostname validation locally against the requested URL, but when an HTTP proxy is configured, proxy-handler inheritance replaces the safe _SafeHTTPHandler and _SafeHTTPSHandler with ProxyHandler instances copied from the global opener. This causes the actual network fetch to be performed by the proxy against a destination that is never re-validated — effectively bypassing the SSRF protection entirely. An attacker can supply a publicly routable URL that passes local validation, while the proxy silently forwards the request to an internal loopback-only service. The vulnerability was confirmed across pathsec.urlopen(), nltk.data.load(), Downloader.index(), and Downloader.download(), and is distinct from the earlier DNS-rebinding fixes addressed in CVE-2026-54296 (NLTK Advisory).

Successful exploitation allows an unauthenticated network attacker to read internal-only HTTP resources by routing requests through a configured proxy, bypassing NLTK's SSRF safeguards. Beyond information disclosure, an attacker can load forged downloader indexes and cause NLTK to install attacker-chosen package content fetched from the proxy's network view, introducing a supply-chain-style integrity risk. The confidentiality impact is rated High, with no direct availability or integrity impact on the vulnerable system itself, though the ability to install arbitrary packages introduces significant downstream integrity risk to affected environments (NLTK Advisory, GitHub Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting very low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires that the target environment has an HTTP proxy configured — either via environment variables (e.g., http_proxy) or an explicit ProxyHandler — which limits the attack surface to deployments with such configurations.

1. Reconnaissance: Identify a target environment running NLTK ≤3.10.2 with an HTTP proxy configured (e.g., via http_proxy environment variable or explicit ProxyHandler).
2. Set up internal target: Deploy or identify a loopback-only HTTP service on the target host (e.g., http://127.0.0.1:PORT/secret) that serves sensitive data, a forged downloader index, or a malicious ZIP payload.
3. Configure proxy forwarding: Control or compromise an HTTP proxy that the target environment uses, and configure it to forward requests for a specific public URL (e.g., http://legitimate-public-host.example.com/resource) to the internal loopback service.
4. Trigger the vulnerable code path: Supply the validated public URL to one of the vulnerable NLTK functions — pathsec.urlopen(), nltk.data.load(), Downloader.index(), or Downloader.download(). The local hostname validation passes because the public hostname is legitimate.
5. Bypass SSRF protection: The proxy-handler inheritance replaces the safe HTTP handlers, and the proxy forwards the request to the internal loopback service. The response from the internal service is returned to the caller without re-validation.
6. Achieve objective: Depending on the targeted function, the attacker can exfiltrate internal HTTP content, inject a forged package index, or cause NLTK to download and install attacker-controlled package content (NLTK Advisory).

• Network: Outbound HTTP requests from the NLTK process to a proxy server targeting URLs that resolve to public hostnames but result in responses consistent with internal services (e.g., unexpected content types, internal hostnames in response headers).
• Network: Proxy access logs showing requests for public URLs being forwarded to loopback or RFC-1918 addresses.
• Logs: Application logs showing NLTK data load or downloader activity with unexpected URLs or content that does not match known NLTK package indexes.
• File System: Unexpected or unrecognized packages installed in the NLTK data directory (default: ~/nltk_data/) that do not correspond to official NLTK corpora or models.
• Process: NLTK downloader processes (Downloader.download()) installing packages from non-standard or unexpected index URLs (NLTK Advisory).

Upgrade NLTK to version 3.10.3 or later, which addresses the vulnerability by refusing proxied fetches under the ENFORCE mode rather than performing them unvalidated. The fix causes pathsec.urlopen() to raise a PermissionError when a proxy is detected and the egress destination cannot be validated. Operators who explicitly trust their proxy infrastructure can opt back in by setting the environment variable NLTK_ALLOW_PROXIED_URLOPEN=1 or nltk.pathsec.ALLOW_PROXIED_FETCH=True. As an interim workaround if patching is not immediately possible, disable or remove HTTP proxy configuration from environments running NLTK, and implement network-level controls (e.g., firewall rules) to prevent the proxy from forwarding requests to internal or loopback addresses (NLTK Advisory, GitHub Advisory).

The vulnerability was reported by researcher sondt99 and assigned high severity by both NVD and the GitHub Advisory Database. VulnCheck published an advisory noting the SSRF protection bypass via proxy. No significant broader media coverage or notable community commentary beyond the official advisory channels has been identified at this time (NLTK Advisory, GitHub Advisory).