CVE-2026-63311

NLTK before version 3.10.0 contains a server-side request forgery (SSRF) flaw (CWE-918) in the validate_network_url() function in nltk/pathsec.py. The _resolve_hostname() helper catches OSError and ValueError raised by socket.getaddrinfo() and returns an empty list, so when DNS resolution fails the validation loop performs no IP checks and the function fails open, letting the subsequent urlopen() proceed without validation; DNS rebinding can similarly defeat the check. An attacker who can induce DNS resolution failures for a target URL or control its DNS records can bypass SSRF protections and reach restricted network resources, including cloud metadata endpoints such as 169.254.169.254, with limited confidentiality and integrity impact (CVSS 4.0 base score 6.9, medium). Any application or service running an affected NLTK version that relies on validate_network_url() to filter outbound URL fetches is affected; this is a deployment-specific exposure rather than a flaw reachable through all NLTK usage. No exploitation in the wild is currently reported: it is not in CISA KEV, EPSS estimates only a 0.2% probability of exploitation in the next 30 days, and one public advisory/PoC reference exists (GHSA-3gqm-fcw5-w839).

What to do: Upgrade to NLTK 3.10.0 or later. If upgrading is not immediately possible, do not rely on validate_network_url() as the sole SSRF guard: add egress allow-lists, block application workloads from reaching the cloud metadata endpoint (169.254.169.254), and fail closed when DNS resolution returns errors. Audit code paths where NLTK fetches remote URLs from user-controlled input, since induced resolution failures or DNS rebinding defeat the validation.