CVE-2026-63311: NLTK Python Library SSRF Vulnerability

CVE-2026-63311 Overview

CVE-2026-63311 is a server-side request forgery (SSRF) vulnerability in the Natural Language Toolkit (NLTK) Python library before version 3.10.0. The flaw resides in the validate_network_url() function in nltk/pathsec.py. The helper _resolve_hostname() catches OSError and ValueError from socket.getaddrinfo() and returns an empty list. When DNS resolution fails, the validation loop performs no IP checks and fails open. An attacker can trigger DNS resolution failures or use DNS rebinding to bypass SSRF protections. This enables access to restricted internal resources, including cloud metadata endpoints such as 169.254.169.254.

Critical Impact
The fail-open validation logic allows attackers to bypass URL allowlisting and reach internal services, including cloud instance metadata endpoints that may expose credentials.

Affected Products

NLTK versions <= 3.9.4
NLTK before 3.10.0
Applications using nltk.pathsec.validate_network_url() for URL validation

Discovery Timeline

2026-08-22 - CVE-2026-63311 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-63311

Vulnerability Analysis

The vulnerability [CWE-918] stems from unsafe error handling inside NLTK's URL validation path. The validate_network_url() function is intended to reject URLs that resolve to private, loopback, link-local, or otherwise restricted IP addresses before invoking urlopen(). Validation relies on _resolve_hostname() to enumerate the IPs a hostname resolves to and iterate each one against a deny list.

When socket.getaddrinfo() raises OSError or ValueError, _resolve_hostname() swallows the exception and returns an empty list. The validation loop then executes zero iterations and returns success. Control returns to the caller, which proceeds to fetch the URL with urlopen() without any address safety check.

This behavior converts a DNS error, which should abort the request, into an implicit approval. Attackers who can influence DNS answers can also exploit the race between the resolution NLTK performs for validation and the resolution urlopen() performs for the actual request, a classic DNS rebinding pattern.

Root Cause

The root cause is fail-open exception handling in _resolve_hostname(). Returning an empty list on resolution failure makes the caller unable to distinguish "no unsafe addresses" from "resolution did not run." The function should either raise, return an error sentinel, or cause validate_network_url() to reject the URL when resolution fails.

Attack Vector

An attacker supplies a hostname that either fails initial resolution or points to a rebinding-controlled DNS server. NLTK's validator returns success. urlopen() then resolves the hostname independently and connects to an internal IP such as 169.254.169.254, 127.0.0.1, or a private RFC1918 address, retrieving cloud metadata, internal APIs, or intranet services.

No authentication is required, and the attack is network-reachable through any application that passes attacker-influenced URLs to the affected NLTK function. Technical details are documented in the GitHub Security Advisory GHSA-3gqm-fcw5-w839 and the VulnCheck advisory.

Detection Methods for CVE-2026-63311

Indicators of Compromise

Outbound HTTP requests from application hosts to cloud metadata endpoints such as 169.254.169.254, metadata.google.internal, or 100.100.100.200.
Python processes loading nltk.pathsec and issuing urlopen() calls to hosts that previously produced DNS resolution errors.
Repeated DNS queries for the same hostname returning different answers within short time windows, consistent with DNS rebinding.
Application logs showing successful URL fetches immediately following getaddrinfo errors.

Detection Strategies

Inventory installed NLTK versions across Python environments and flag any version at or below 3.9.4.
Monitor egress traffic from application servers and containers for connections to link-local, loopback, and RFC1918 destinations initiated by Python runtimes.
Add code-level logging around calls to validate_network_url() to record the resolved IP list, hostname, and validation outcome.
Correlate DNS query telemetry with subsequent HTTP fetches to identify rebinding patterns.

Monitoring Recommendations

Alert on any application-originated request to 169.254.169.254 or cloud provider metadata hostnames from workloads that should not access them.
Track NLTK package versions in software bill of materials (SBOM) pipelines and CI dependency scans.
Capture DNS resolver logs and flag high-frequency low-TTL responses to hostnames used by application code paths.

How to Mitigate CVE-2026-63311

Immediate Actions Required

Upgrade NLTK to version 3.10.0 or later in all production and development environments.
Audit application code that passes user-supplied URLs to NLTK to determine exposure of the validate_network_url() code path.
Restrict outbound network access from workloads that process untrusted URLs, blocking link-local, loopback, and metadata IP ranges at the network layer.
Enforce Instance Metadata Service v2 (IMDSv2) on AWS and equivalent header-bound metadata protections on other cloud providers to reduce impact if SSRF succeeds.

Patch Information

The fix is included in NLTK 3.10.0. Update via pip install --upgrade 'nltk>=3.10.0' and rebuild container images that pin earlier versions. See the NLTK security advisory for full remediation guidance.

Workarounds

Wrap calls to validate_network_url() with application-level logic that rejects any hostname whose DNS resolution raises an exception.
Perform SSRF validation independently using a hardened library and pass only pre-validated IP literals to downstream fetch calls.
Deploy an egress proxy that enforces destination allowlisting for all outbound HTTP requests from Python services.
Disable NLTK features that fetch remote resources in environments where the functionality is not required.

bash

# Configuration example
pip install --upgrade 'nltk>=3.10.0'
pip show nltk | grep -i version