NLTK CVE-2026-70626

Exploitation requires that the attacker have write access to the corpus root directory or any of its subdirectories on the host filesystem, enabling symlink creation. The vulnerable NLTK application must then invoke CorpusReader.open() on a path that resolves - via the attacker's symlink - to a file outside the corpus boundary. Purely remote attackers with no local filesystem write access cannot exploit this vulnerability. No special NLTK configuration or non-default feature flag is required: any application using the CorpusReader API on a system where untrusted local users share write access to the corpus directory is exposed. The scope of readable files is bounded by the OS-level permissions of the process executing NLTK - only files that process can open are accessible via the symlink escape.

The provided CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) scores 8.6, but several metrics are in tension with the vulnerability description. AV:L correctly reflects that symlink placement requires local filesystem write access. However, VI:H (high integrity impact) and VA:H (high availability impact) are not supported by the description, which describes only arbitrary file read; no write or crash primitive is documented. These ratings appear to be conservatively estimated rather than empirically confirmed and should be verified against the vendor advisory at GHSA-r6gq-whwq-mvg9. VC:H is well-supported: the NLTK process may read any file it has OS-level permission to access, potentially exposing application secrets, private keys, or OS credential files. No EPSS score was provided in the intelligence data; the vulnerability is absent from the CISA KEV catalog, and no proof-of-concept code has been identified, indicating no confirmed active exploitation. The local attack vector is the primary limiting factor: purely remote attackers with no write access to the corpus directory cannot exploit this flaw. Real-world risk is most acute in multi-tenant environments, CI/CD pipelines with shared corpus directories, or containerized deployments where untrusted users have write access to NLP data paths.

An attacker with write access to an NLTK corpus directory - for example, a low-privileged user on a shared NLP workstation or a compromised CI build step - creates a symbolic link named corpus_file.txt inside the corpus root pointing to /etc/shadow or an application's .env secrets file. When the NLTK application subsequently calls CorpusReader.open('corpus_file.txt'), the lexical path check passes because the symlink's path string is within the corpus root; the OS resolves the link, and NLTK returns the contents of the sensitive target file to the caller. No public proof-of-concept has been identified, but the technique is a well-understood class of local privilege escalation and requires no specialized tooling beyond the ability to run ln -s.