KEVWire

Security intelligence, with context.

Response snapshot Oct 27, 2026, 13:06 UTC

Back to the wire
Permalink
VulnerabilityCVE-2026-63311

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

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.

Published Updated

At a glance

Exploited
Not known
Severity
6.9 Medium (CVSS 4.0)
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: nltk: 3.10.0. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-3gqm-fcw5-w839 (opens a new tab)

What happened

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

Continue reading

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

Affected package ranges reported by GitHub: nltk: <= 3.9.4

Scores and how they were measured

CVSS base severity

6.9

Version 4.0As of

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L

Measurement source (opens a new tab)

How bad it is if exploited. Not a prediction of exploitation or proof you are exposed.

EPSS probability

Not available

A model's estimate of exploitation in the next 30 days, not certainty or your own risk.

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-3gqm-fcw5-w839 (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-3gqm-fcw5-w839, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 27). NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure (CVE-2026-63311). https://kevwire.com/record/CVE-2026-63311

MLA

"NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure (CVE-2026-63311)." KEVWire, 27 Oct. 2026, kevwire.com/record/CVE-2026-63311.

Chicago

KEVWire. "NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure (CVE-2026-63311)." Last modified October 27, 2026. https://kevwire.com/record/CVE-2026-63311.

Evidence summary (plain text)

NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure (Sep 2, 2026).
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.
CVSS 6.9 (version 4.0; evidence as of Oct 27, 2026; https://github.com/advisories/GHSA-3gqm-fcw5-w839).
Sources:
GitHub-reviewed advisory GHSA-3gqm-fcw5-w839: https://github.com/advisories/GHSA-3gqm-fcw5-w839
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: CVE-2026-63311.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 27, 2026, 11:45 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are not available yet. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail