CVE-2026-63311: Server-Side Request Forgery and DNS Rebinding in Natural Language Toolkit (NLTK)

The Natural Language Toolkit (NLTK) is a widely used Python library for processing human language data. In versions prior to 3.10.0, NLTK implemented a security sentinel in nltk/pathsec.py designed to filter outbound network connections. This filter aimed to prevent Server-Side Request Forgery (SSRF) and local directory traversal attacks during resource fetching.

The target attack surface consists of functions that dynamically fetch remote data, such as nltk.download() or nltk.data.load(). When these functions receive user-supplied URLs, they rely on the validation module to block malicious requests. The original implementation attempted to verify hostnames prior to establishing HTTP connections, but contained fatal logic design flaws.

Two critical weaknesses undermine the filter's security guarantees. First, the DNS validation loop fails open if the DNS query encounters an exception. Second, the absence of socket-level IP pinning allows Time-of-Check to Time-of-Use (TOCTOU) DNS rebinding attacks. These weaknesses allow an unauthenticated attacker to route HTTP requests to internal subnets, local loopback interfaces, or cloud provider metadata endpoints.

The root cause of the vulnerability lies in the implementation of the validate_network_url() function in nltk/pathsec.py. The function attempts to resolve target hostnames and verify that the corresponding IP addresses do not belong to private, loopback, or multicast ranges.

The first critical vulnerability involves fail-open error handling in the DNS resolver. The helper function _resolve_hostname() wraps socket.getaddrinfo() inside a try-except block. If the DNS query fails due to a network timeout, an invalid hostname format, or a deliberate DNS resolution error, the function catches the exception and returns an empty list.

@lru_cache(maxsize=256)
def _resolve_hostname(hostname):
    try:
        return socket.getaddrinfo(hostname, None, proto=socket.IPPROTO_TCP)
    except (OSError, ValueError):
        return []

Because the resolver returns an empty list, the verification loop in the calling function executes zero iterations. No IP addresses are evaluated against the forbidden lists, and the validation completes successfully without raising any security exceptions. The application then proceeds to establish a network connection using urllib.request.urlopen().

The second critical flaw is a Time-of-Check to Time-of-Use (TOCTOU) race condition. Even when DNS resolution succeeds, the validated IP address is never pinned to the actual HTTP request. The library validates the IP during the check stage, but the underlying HTTP client performs a separate DNS resolution when establishing the TCP socket. This architecture permits DNS rebinding, where an attacker-controlled DNS server yields a safe IP during validation and a local IP during execution.

The security patch introduced in NLTK version 3.10.0 completely replaces the vulnerable pre-check validation logic with active socket-level IP pinning. The patch intercepts connection attempts to force the application to connect exclusively to the specific, validated IP addresses.

# Patched implementation of host resolution and validation
def _resolve_and_validate_host(host, port):
    try:
        addrinfo = socket.getaddrinfo(host, port, proto=socket.IPPROTO_TCP)
    except (OSError, ValueError):
        # FAIL CLOSED: Resolution failures now abort the request
        return []
    
    validated = []
    for res in addrinfo:
        ip_str = res[4][0]
        ip = ipaddress.ip_address(ip_str)
        if _ip_is_forbidden(ip):
            # Explicitly block access to local, private, or non-global routes
            raise PermissionError(f"SSRF attempt to blocked IP {ip_str}")
        validated.append(res)
    return validated

The patched library subclasses http.client.HTTPConnection and http.client.HTTPSConnection to implement safe connections. When making a connection, the custom handler resolves the hostname, validates every returned IP address, and establishes the TCP socket directly using the numeric IP. This avoids the second DNS lookup, neutralizing the TOCTOU rebinding vector.

This fix is highly complete and robust. It addresses the architectural flaws of the previous implementation by eliminating the split-resolution pattern and ensuring that DNS resolution failures result in a hard failure rather than a silent bypass.

Exploitation of CVE-2026-63311 requires the attacker to influence the URL parameter passed to NLTK's data-fetching functions. The attack vector depends on whether the target application accepts user-specified download mirrors or directly parses documents containing resource links.

In a DNS rebinding attack, the adversary registers a custom domain (such as rebind.attacker.com) and configures an authoritative DNS server under their control. The DNS server is programmed to alternate its responses or set the Time-To-Live (TTL) value of the record to 0. This ensures that the server does not allow downstream caching of the resolved IP.

When NLTK processes the input URL, the validation engine queries the DNS server. The DNS server returns a public IP address. The validation check evaluates this public IP, determines it is safe, and permits execution. Immediately afterward, the HTTP connection client requests resolution again. The DNS server now returns 127.0.0.1 or 169.254.169.254, forcing the application server to connect to its own local services or its cloud provider's metadata endpoint.

The impact of successful exploitation depends heavily on the execution environment. In cloud-deployed applications, such as Python services running on AWS, GCP, or Azure, the vulnerability provides a direct pathway to compromise the host. Attackers can query the cloud provider metadata service to retrieve sensitive IAM credentials, internal service configurations, and authentication tokens.

When deployed within internal networks, the vulnerability transforms the host application into an open proxy. Attackers can conduct internal port scanning and send unauthorized HTTP GET requests to local databases, cache systems, or internal APIs that trust requests originating from localhost. The vulnerability does not directly support arbitrary file writing or command execution, but can be chained with other local vulnerabilities to achieve Remote Code Execution (RCE).

The CVSS v4.0 base score is rated at 6.9, reflecting network-based, low-complexity attacks that require no prior privileges or user interaction. The impact is primarily categorized as low integrity and low confidentiality, because the standard urllib implementation limits the attacker to read-only HTTP GET requests without the ability to modify server state directly via other methods.

The primary remediation strategy is upgrading the NLTK installation to version 3.10.0 or higher. This upgrade can be performed via the standard package management utilities. The updated library contains the socket-level pinning modifications that neutralize both the fail-open and DNS-rebinding behaviors.

pip install --upgrade nltk>=3.10.0

If patching the software dependency is not immediately feasible, organizations should implement host-level or network-level firewall rules. Administrators can block outbound HTTP/HTTPS requests from the application server to private subnets (RFC 1918) and the cloud metadata range (169.254.169.254/32). These egress blocks prevent successful exploitation even if the library continues to permit the requests.

Furthermore, local DNS resolvers can be configured to drop responses that resolve external domains to private IP addresses. Implementing anti-DNS-rebinding filters at the resolver level provides a robust layer of defense against this class of vulnerabilities across the entire infrastructure.