NLTK CVE-2026-63311

Exploitation requires all three of the following: (1) the target application must invoke NLTK's validate_network_url() function or a higher-level NLTK function that calls it, with a URL value that the attacker can influence - NLTK itself is a library and does not expose a network service, so the application's exposure surface determines whether this condition is met; (2) the attacker must be able to engineer a DNS resolution failure for the supplied hostname (e.g., by supplying a domain returning NXDOMAIN, or controlling DNS to produce an OSError or ValueError from socket.getaddrinfo()) or execute a DNS rebinding attack where a domain resolves to a permitted public IP during validation but to a restricted internal IP at request time; (3) for the highest-impact scenario, the deployment environment must have a reachable link-local metadata endpoint (169.254.169.254) without IMDSv2 or equivalent enforcement. Exploitation is bounded by the requirement to influence URL input into NLTK functions, the need for DNS control or the ability to cause deliberate resolution failures, and the absence of network-layer egress filtering on the host process.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L) yields a score of 6.9, characterizing this as a remotely exploitable, low-complexity flaw with no authentication requirement and collateral impact on subsequent systems. The low-complexity rating is worth scrutiny: DNS rebinding requires the attacker to control DNS infrastructure for a domain and engineer precise timing windows, which is non-trivial; however, simply using a hostname that produces a DNS resolution failure (e.g., NXDOMAIN, or triggering an OSError/ValueError from socket.getaddrinfo()) may be considerably easier and lowers the practical bar. No EPSS data was provided, no CISA KEV listing exists, and no proof-of-concept exploit has been identified - all signals that reduce immediate mass-exploitation risk. However, for cloud-deployed applications that expose NLTK network-fetch functionality to user-supplied input, the real-world risk is meaningfully higher than the moderate CVSS score implies: successful exploitation targeting 169.254.169.254 in AWS, GCP, or Azure environments without IMDSv2 enforcement can yield IAM role credentials and enable privilege escalation. In non-cloud environments or deployments where NLTK is not exposed to attacker-influenced URL input, practical risk is low.

An attacker submits a crafted URL referencing a hostname they control to a web application that passes user-supplied URLs into an NLTK network-fetch function. By configuring that hostname to return NXDOMAIN or otherwise trigger an OSError in socket.getaddrinfo(), the SSRF validation in validate_network_url() iterates an empty list, performs no IP checks, and allows urlopen() to proceed. The attacker then uses a redirect or DNS rebinding technique to resolve the hostname to 169.254.169.254 at request time, retrieving AWS instance metadata including attached IAM role credentials. No public proof-of-concept has been identified at time of analysis.