CVE-2026-78682
PoC nicheSSRF Protection Bypass in NLTK (pathsec) When a Proxy Is Configured
CVE-2026-78682 is a server-side request forgery (SSRF, CWE-918) protection bypass in NLTK's pathsec module: `pathsec.urlopen()` validates the requested hostname locally, but when an HTTP proxy is configured, proxy-handler inheritance from the global opener replaces the pinned `_SafeHTTPHandler`/`_SafeHTTPSHandler` handlers, so the real request is made through the proxy without the destination being pinned to the validated host/IP. It is triggered by any proxied fetch through `pathsec.urlopen()`, `nltk.data.load()`, `Downloader.index()`, or `Downloader.download()` — for example, a validated public URL can be forwarded by the proxy to an internal loopback-only service, and the internal response is returned, parsed as a downloader index, and installed. An attacker who can influence proxied fetch destinations gains the ability to read internal-only HTTP resources (high confidentiality impact, CVSS 4.0 score 8.7), have forged downloader indexes accepted, and install attacker-chosen package content fetched from the proxy's network view. Affected users are Python (pip) applications running the v3.10.0-rc2 code with an HTTP proxy configured that rely on pathsec as an SSRF barrier; the published 3.9.4 release was tested as a negative control and did not reproduce, and no patched version exists yet. Exploitation is not currently known: EPSS estimates a 0.3% probability of exploitation within 30 days, the flaw is not in CISA KEV, and no public PoC is known.
What to do: No patched NLTK release exists yet, so pin to the published 3.9.4 release (confirmed unaffected) and avoid running the v3.10.0-rc2 source/RC in environments with an HTTP proxy configured until a fix is issued. If you must run affected code, do not treat pathsec as a complete SSRF barrier — enforce destination allowlists and egress controls at the proxy or network layer so proxied fetches cannot reach internal-only services, and review whether `nltk.data.load()` and downloader fetches can be reached with attacker-influenced URLs. Monitor the nltk GitHub repository for a patched release and regression tests covering proxied fetches.
| NLTK (nltk project) NLTK (nltk Python package, pip ecosystem) | v3.10.0-rc2 (release-candidate/source; not yet patched; published 3.9.4 confirmed not affected) |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vendors
- nltk
- Products
- nltk
- Ecosystems
- pip
- Weakness
- CWE-918
- Vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
- GHSA
- GHSA-6ww7-3frv-cqxh (high)
In the news0 stories
No ingested article mentions this CVE yet.