GHSA-3gqm-fcw5-w839: SSRF
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.
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 - Configuration
In nltk/pathsec.py, modify validate_network_url()/validation flow so that if _resolve_hostname() returns an empty result [] (e.g., because socket.getaddrinfo raises OSError/ValueError and _resolve_hostname() returns []), the function MUST fail closed by raising a SecurityError or otherwise returning a failure status. This prevents urlopen() from proceeding to make the request without IP validation when DNS resolution is unavailable.
NLTK pathsec (nltk/pathsec.py) validate_network_url fail-closed behavior when _resolve_hostname returns empty list = raise SecurityError (reject URL) - Compensating control
Until the code is patched, mitigate SSRF exposure to cloud metadata endpoints by blocking outbound requests to AWS IMDS 169.254.169.254 and GCP metadata from the affected environment (e.g., via firewall/egress rules or network ACLs/WAF URL filtering), since the advisory identifies cloud metadata endpoints as attack targets.
Event History
Frequently Asked Questions
Under what conditions can the URL validation be bypassed?
The bypass occurs when DNS resolution for the target hostname raises an OSError or ValueError. The resolver helper returns an empty address list, so validation completes without checking any resolved IP address and the request is allowed to proceed.
Are deployments with unstable DNS resolution at particular risk?
Yes. If the resolver is unreliable, DNS lookup errors can repeatedly cause the validation to fail open, effectively bypassing the SSRF protection whenever those errors occur. The advisory also states that a temporary DNS outage disables all SSRF protections.
Can DNS rebinding be used to bypass the validation?
Yes. The advisory states that DNS rebinding can bypass the check after the LRU cache entry expires, allowing a hostname's resolution to change after cached validation information is no longer used.
How can I determine whether the vulnerable behavior is present?
Simulate a DNS-resolution failure by making socket.getaddrinfo() raise OSError, then call nltk.pathsec.validate_network_url() with a sensitive URL such as a link-local metadata address. If the function returns normally rather than rejecting the URL, the fail-open behavior is present.