NLTK CVE-2026-62383

Exploitation requires three concrete preconditions: (1) the attacker has local write access to the specific filesystem directory configured as the NLTK corpus root for an IPIPANCorpusReader instance; (2) the target application instantiates IPIPANCorpusReader and invokes one of the vulnerable methods - channels(), domains(), categories(), or fileids() - during normal operation or in response to attacker-influenced input; (3) NLTK is running at version earlier than 3.10.2. Exploitation is further limited to files readable by the OS user account under which the NLTK process runs; root-owned files are not accessible if the process runs as an unprivileged user. IPIPANCorpusReader is a non-default, specialized reader not instantiated unless explicitly coded, restricting the exposed surface to applications that specifically process IPIPAN Polish corpus data. No network access is required; this is a purely local attack path.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) accurately characterizes the threat: local access is required, complexity is low once preconditions are met, and low OS-level privileges suffice if the attacker can write to the corpus directory. High confidentiality impact reflects the ability to read any file the NLTK process can access. No EPSS data was provided. There is no KEV listing and no confirmed POC, so this is assessed as no public exploit identified at time of analysis. Real-world priority depends heavily on deployment context: shared research compute environments or multi-tenant NLP pipelines where untrusted users can influence corpus directory contents face meaningful risk, while single-user workstations or containerized inference services with controlled corpus paths face negligible exposure. The specialized nature of IPIPANCorpusReader - a Polish corpus reader not used by default - further narrows the affected population.

A local attacker with write access to the NLTK corpus root directory creates a symbolic link named to resemble a valid IPIPAN corpus file, pointing the link target to a sensitive path such as /etc/shadow, an SSH private key, or an application secrets file. When the target application subsequently calls IPIPANCorpusReader().fileids() or a similar method that resolves the symlink name, NLTK follows the symlink and returns the contents of the sensitive file without triggering pathsec validation. No public proof-of-concept has been identified at time of analysis, but the technique is mechanically straightforward for any attacker with the necessary write access.