NLTK EUVD-2026-64309

Exploitation requires that the attacker can control or influence the string argument passed to nltk.data.load(), and that the application uses a version of NLTK earlier than 3.10.0. The most common at-risk configuration is an application or API endpoint that accepts user-supplied resource names, corpus identifiers, or model paths and forwards them to NLTK data loading without validating or allowlisting the value. The file:// URL scheme must be accepted by the application's invocation path; in default NLTK usage this scheme is valid. The CVSS PR:L rating confirms that some level of authenticated or authorized access is required - purely unauthenticated, zero-touch exploitation is not indicated. Exploitation is limited to reading files accessible to the OS account running the NLTK process; files owned by root with restrictive permissions would not be readable unless the process runs as root. No special NLTK configuration, non-default settings, or specific platform is required beyond using an affected version with user-controlled input reaching nltk.data.load().

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) accurately captures the threat profile: network-reachable, low complexity, no attack requirements, but requiring some level of prior access (PR:L). The high confidentiality impact (VC:H) with no integrity or availability impact is consistent with a pure read primitive. The PR:L constraint is the primary limiting factor - exploitation requires the ability to influence what string is passed to nltk.data.load(), which in practice means the attacker either has authenticated access to an application using NLTK or the application exposes an interface that passes user input to this function without sanitization. The absence of a CISA KEV listing and the lack of noted public exploit code reduce urgency relative to a fully unauthenticated, weaponized flaw, but the self-comparison bug is so straightforward that exploit development would be trivial for any researcher with NLTK familiarity. EPSS data was not provided in the input; risk should be treated as moderate-to-high for any deployment where NLTK data loading accepts external or user-controlled identifiers. Impact is confined to confidentiality - no write or destructive capability is exposed.

An attacker with authenticated access to a web application that uses NLTK for text processing submits a crafted file:// URL - such as file:///etc/passwd or file:///app/.env - as a resource identifier to an endpoint that internally calls nltk.data.load() with the user-supplied value. FileSystemPathPointer.open() invokes its sandbox check, which compares the normalized path against itself (always True), silently passes, and returns the file contents to the application, which may then echo them in an error message or API response. No public exploit code has been identified at time of analysis, but the logic defect requires no heap spray, memory corruption, or race condition - only a valid file:// URL pointing to a readable file.