NLTK EUVD-2026-65228

Exploitation requires that an HTTP proxy be configured in the environment running NLTK - typically via the HTTP_PROXY or HTTPS_PROXY environment variables or equivalent urllib proxy settings. Without a proxy, the safe URL handlers remain in place and the SSRF bypass does not occur. Additionally, the attacker must be able to supply a URL (or influence one) that is passed to nltk.pathsec.urlopen, nltk.data.load, Downloader.index, or Downloader.download; in many deployments these are called with hardcoded internal resource paths, limiting exploitability. Exploitation is further constrained to HTTP-reachable internal targets that the proxy can forward to. Limiting factors: non-default proxy configuration required; attacker must control or influence the URL argument; targets limited to HTTP-accessible internal services reachable from the proxy host.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N) places this at a high base score, but several factors modulate real-world priority. The most important limiting factor is the proxy requirement: NLTK deployments without a configured HTTP proxy are not exploitable, substantially shrinking the vulnerable population relative to the unauthenticated network vector alone. Conversely, the description reveals an integrity impact - forged downloader indexes enabling installation of attacker-chosen package content - that the base vector's VI:N does not capture, suggesting the provided CVSS 4.0 vector underestimates actual impact. VulnCheck has published an advisory but no CISA KEV listing or confirmed public exploit code exists at time of analysis; EPSS probability data was not provided. The realistic priority is moderate-to-high for proxy-configured CI/CD pipelines, shared NLP inference infrastructure, and any service that passes user-influenced URLs to nltk.data.load at runtime; organizations running NLTK in airgapped or proxy-free environments face negligible risk from this specific vector.

An attacker targeting a data-science API that accepts a user-supplied corpus URL and passes it to nltk.data.load constructs a URL pointing to a legitimate public hostname. Because the deployment runs behind a corporate HTTP proxy, the proxy resolves the supplied hostname to an internal metadata service (e.g., 169.254.169.254 on a cloud instance); NLTK's local validation cleared the public hostname and never re-checks the proxy's resolved destination. The proxy returns the metadata service's response to the attacker, disclosing cloud credentials or internal configuration. No public exploit code has been identified at time of analysis.