NLTK before 3.10.0 SSRF via DNS Resolution Failure
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| nltk | nltk | unaffected |
|
No data.
| Vendor | Product | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Nltk | Nltk |
|
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-3gqm-fcw5-w839 | NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure |
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.334% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | NLTK before 3.10.0 (affected versions <= 3.9.4) contains a server-side request forgery (SSRF) vulnerability in the validate_network_url() function in nltk/pathsec.py. The _resolve_hostname() 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). | |
| Title | NLTK before 3.10.0 SSRF via DNS Resolution Failure | |
| First Time appeared |
Nltk
Nltk nltk |
|
| Weaknesses | CWE-918 | |
| CPEs | cpe:2.3:a:nltk:nltk:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Nltk
Nltk nltk |
|
| References |
| |
| Metrics |
cvssV3_1
|