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).
Other sources
There is an SSRF vulnerability in NLTK 3.9.4's network URL validation. The validatenetworkurl() function in nltk/pathsec.py fails open when DNS resolution returns an error.
The resolvehostname() helper at lines 193-234 catches OSError and ValueError during socket.getaddrinfo() and returns an empty list []. When this happens, the validation loop in validatenetworkurl() iterates over nothing (for addr in resolved: ... never executes), with no else/fallback check. The function returns normally, and urlopen() proceeds to make the request without any IP validation.
This means: 1. If DNS is temporarily unavailable, ALL SSRF protections are disabled 2. DNS rebinding attacks bypass the check after the LRU cache entry expires 3. In environments with unreliable resolvers, the protection is permanently bypassed
PoC: python import nltk.pathsec import unittest.mock
Simulate DNS failure with unittest.mock.patch('socket.getaddrinfo', sideeffect=OSError('DNS unavailable')): # This SHOULD raise but doesn't -- fails open nltk.pathsec.validatenetworkurl('http://169.254.169.254/latest/meta-data/') # Returns normally, allowing SSRF to cloud metadata
The correct behavior is fail-closed: if DNS resolution fails, the URL should be REJECTED (not allowed). The function should raise an exception or return a failure status when resolvehostname() returns an empty list.
This is distinct from CVE-2024-39705 (which addressed pickle deserialization) and CVE-2026-33236 (which addressed XML path traversal). This finding targets the newly-added pathsec.py security layer introduced to fix those earlier issues.
Suggested fix: Add an explicit check after resolvehostname() returns: if the result is empty, raise a SecurityError. Never allow a URL request to proceed when IP validation was impossible.
CVSS Note: The CVSS use SC:H (High subsequent confidentiality) because the advisory explicitly identifies cloud metadata endpoints (169.254.169.254) as an attack target. Access to AWS IMDS or GCP metadata exposes credentials or service account tokens, which constitutes High-impact disclosure on downstream systems. This justifies SC:H over NVD's SC:L.
— GitHub
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/nltkto a version that resolves this vulnerability.Fixed in 3.10.0 - Upgrade
Upgrade
nltkto a version that resolves this vulnerability.Fixed in 3.10.0 - Configuration
In nltk/pathsec.py validate_network_url(), after _resolve_hostname() returns, add an explicit post-check: if the returned result is empty ([]), raise a SecurityError (or otherwise fail closed) so the URL request does NOT proceed to urlopen() when DNS resolution fails.
NLTK pathsec (nltk/pathsec.py) - validate_network_url() fail_closed behavior when _resolve_hostname() returns an empty list = reject when _resolve_hostname() returns [] (raise SecurityError / raise exception)
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.