CVE-2026-63311: NLTK before 3.10.0 SSRF via DNS Resolution Failure
NLTK before 3.10.0 (affected versions <= 3.9.4) contains a server-side request forgery (SSRF) vulnerability in the validatenetworkurl() function in nltk/pathsec.py. The resolvehostname() helper catches OSError and ValueError during socket.getaddrinfo() and returns an empty list; when DNS resolution fails, the validation loop executes no IP checks and the function fails open, allowing urlopen() to proceed without validation. An attacker who can trigger DNS resolution failures or use DNS rebinding can bypass SSRF protections and reach restricted network resources, including cloud metadata endpoints (e.g., 169.254.169.254).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
NLTK (nltk/pathsec.py validate_network_url())to a version that resolves this vulnerability.Fixed in 3.10.0 - Configuration
Modify or upgrade NLTK so that validate_network_url() does not fail open when _resolve_hostname() cannot resolve a hostname (e.g., when socket.getaddrinfo() raises OSError/ValueError and _resolve_hostname() returns an empty list).
NLTK (nltk/pathsec.py validate_network_url()) validate_network_url() DNS failure handling (fail-closed instead of failing open) = Return an error / stop validation when _resolve_hostname() returns an empty list after catching OSError or ValueError (instead of executing no IP checks). - Compensating control
Block or strictly restrict outbound access from the affected service to cloud metadata endpoints such as 169.254.169.254 (and other restricted network resources) using network controls (firewall/ACL) to prevent SSRF reachability even if URL validation is bypassed.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using affected NLTK versions that rely on validate_network_url() to restrict outbound URL access are exposed. The risk is greatest where an attacker can influence a URL that the application later fetches with urlopen().
What does an attacker need to exploit the bypass?
An attacker needs to cause DNS resolution to fail or use DNS rebinding for a hostname supplied to the URL-validation path. When resolution fails, the helper returns no addresses and the validation performs no IP checks before urlopen() proceeds.
Are restricted internal addresses protected when DNS lookup fails?
No. A DNS-resolution failure causes the validation to fail open, so the URL may be fetched without checks that would otherwise block restricted IP addresses, including cloud metadata endpoints such as 169.254.169.254.
Which versions are affected?
NLTK versions before 3.10.0 are affected; the provided affected range is versions 3.9.4 and earlier.