NLTK before 3.10.3 SSRF Protection Bypass via Proxy
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-6ww7-3frv-cqxh | NLTK: pathsec SSRF protection can be bypassed when a proxy is configured |
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.435% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | NLTK before 3.10.3 contains a server-side request forgery vulnerability in nltk.pathsec.urlopen (and callers nltk.data.load, nltk.downloader.Downloader.index/download) when an HTTP proxy is configured. pathsec.urlopen validates the requested hostname locally, but proxy-handler inheritance disables the safe HTTP/HTTPS handlers so the actual fetch is performed by the proxy against a destination that is never re-validated. An attacker can supply a validated public URL that the proxy forwards to an internal loopback-only service, allowing disclosure of internal HTTP resources, loading of forged downloader indexes, and installation of attacker-chosen package content. | |
| Title | NLTK before 3.10.3 SSRF Protection Bypass via Proxy | |
| 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
|