NLTK pathsec SSRF protection bypass with proxy configured

Severity: high · CVSS 7.5 · Published 2026-08-25

NLTK is a widely-used Python library for natural language processing that includes functions to safely download data files from the internet. A security flaw in NLTK's proxy handling allows attackers to bypass the library's built-in protections against accessing internal company systems. An attacker can trick NLTK into fetching data from internal-only servers by routing requests through a proxy, potentially exposing sensitive internal resources or installing malicious code on affected systems.

Technologies: nltk (PyPI). Vendors: PyPI.

Quick answers

Is This vulnerability exploited in the wild?
No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
How severe is This vulnerability?
High severity, with a CVSS score of 7.5, published 25 August 2026.
Which products and versions are affected?
nltk (PyPI) <= 3.10.2.
Is there a fix for This vulnerability?
A patch was published on 2026-08-11: Fix released in NLTK 3.10.3 or later Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is This vulnerability attacked?
It is attacked over the network, in a software library.
Am I affected?
Check whether you run nltk (PyPI) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is a server-side request forgery (SSRF) in nltk.pathsec.urlopen() and its callers (nltk.data.load(), nltk.downloader.Downloader.index(), nltk.downloader.Downloader.download()). The root cause is that when an HTTP proxy is configured, pathsec validates the destination hostname locally but then disables safe HTTP/HTTPS handlers (_SafeHTTPHandler and _SafeHTTPSHandler), allowing the actual fetch to be performed by the proxy against a never-re-validated destination. An attacker can supply a validated public URL that the proxy forwards to an internal loopback-only service (127.0.0.1). The vulnerability requires an HTTP proxy to be configured in the environment and affects NLTK versions up to 3.10.2. The attack is network-accessible with no authentication or user interaction required. A fix is available in NLTK 3.10.3 and later, which enforces validation or fails closed when proxied requests would otherwise bypass pinned handlers.

Affected products

  • NLTK Project NLTK < 3.10.3

Timeline

  • 2026-08-11: disclosed: Original advisory GHSA-6ww7-3frv-cqxh published on GitHub
  • 2026-08-25: disclosed: Duplicate advisory GHSA-crp9-r7rq-c8cg and CVE-2026-78682 published
  • 2026-08-11: patched: Fix released in NLTK 3.10.3 or later

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.