Patch Forecast
Yellow warning
Plan into this sprint.

CVE-2026-63311 · GHSA-3gqm-fcw5-w839

NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure

Risk score
46/100
CVSS
6.9 v4.0
Published
2 Sep 2026

Open in the live forecast Today's forecast

What to know

What it is
There is an SSRF vulnerability in NLTK 3.9.4's network URL validation. The validate_network_url() function in nltk/pathsec.py fails open when DNS resolution returns an error. The _resolve_hostname() helper at lines 193-234 catches OSError and ValueError during socket.getaddrinfo() and returns an empty list []. When th…
Affected
nltk (pip) <= 3.9.4
Fix
Upgrade nltk to 3.10.0 or later.
Exploitation
No known exploitation

Story map

Story map: nltkTHE FLAWSTHE FIXCVE-2026-63311NLTK: SSRF Fail-Open invalidate_network_url() via DNSResolution FailureCVSS 6.9GHSA-j456-xh4h-cpf2NLTK: WekaClassifier passes anunvalidated caller-controlledmodel path to the weka JVM…CVSS 8.6CVE-2026-62388NLTK: Default ENFORCE=FalseDisables All pathsec SecurityControlsCVSS 8.7FixUpgrade to version 3.10.4 orlaterWho is exposed{'products': ['NLTK'],'packages': [{'ecosystem': 'pip','name': 'nltk', 'vulnerable': '<=3.10.3', 'patched': '3.10.4'}]}AMBER · PATCH THIS WEEKnltkThe NLTK library'sWekaClassifier passesunvalidated caller-controlledmodel paths to the weka JVM,allowing an attacker to bypasscontainment and potentiallywrite arbitrary files or…Where it standsPublic proof of conceptCONNECTS TOSame weaknessServer-side request forgery (CWE-918)237 other warnings in 30 days →
Story map: the flaws, the fix, how it unfolded and what it connects to. Boxes link to the record or article.

At a glance

nltk: Amber, patch this week. The NLTK library's WekaClassifier passes unvalidated caller-controlled model paths to the weka JVM, allowing an attacker to bypass containment and potentially write arbitrary files or read/parse files from any location.

The flaws

  • CVE-2026-63311: NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure (CVSS 6.9)
  • GHSA-j456-xh4h-cpf2: NLTK: WekaClassifier passes an unvalidated caller-controlled model path to the weka JVM, bypassing nltk.pathsec containment (CVSS 8.6)
  • CVE-2026-62388: NLTK: Default ENFORCE=False Disables All pathsec Security Controls (CVSS 8.7)

The fix

Fix: Upgrade to version 3.10.4 or later

Who is exposed: {'products': ['NLTK'], 'packages': [{'ecosystem': 'pip', 'name': 'nltk', 'vulnerable': '<= 3.10.3', 'patched': '3.10.4'}]}

Where it stands

  • Public proof of concept

Connects to

Why it is Yellow

  • CVSS 6.9 medium
  • On your watchlist: PyPI

Affected packages

PackageEcosystemVulnerableFixed in
nltkpip<= 3.9.43.10.0

References

Original description

There is an SSRF vulnerability in NLTK 3.9.4's network URL validation. The validate_network_url() function in nltk/pathsec.py fails open when DNS resolution returns an error. The _resolve_hostname() helper at lines 193-234 catches OSError and ValueError during socket.getaddrinfo() and returns an empty list []. When this happens, the validation loop in validate_network_url() 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', side_effect=OSError('DNS unavailable')): # This SHOULD raise but doesn't -- fails open nltk.pathsec.validate_network_url('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 _resolve_hostname() 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 _resolve_hostname() 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.

Last activity 2 Sep 2026. Patch Forecast updates every hour.