NLTK EUVD-2026-64338

Exploitation requires that the attacker has write access to an NLTK FrameNet corpus subdirectory on the target host - a condition present in shared research environments, world-writable corpus installations, or pipelines where multiple user accounts share a corpus directory. The attacker must also be able to create symbolic links, which is a standard capability for any local Unix user account. Exploitation is triggered when a separate, more privileged process (with broader filesystem read access) calls frame_by_name(), _lu_file(), or doc() using the attacker-controlled symlink name. Limiting factors include: the necessity of local filesystem write access to the specific corpus directory (not merely network access); the requirement that the NLTK service process has OS-level read access to the intended target file; and the constraint that only files parseable as XML can be exfiltrated without errors, which may restrict the range of useful targets. The vulnerability does not apply when the corpus directory is owned exclusively by the NLTK service account with no write access granted to other users.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 8.7) materially overstates network accessibility: creating a filesystem symlink requires local write access to the corpus directory, making this a local-privilege information-disclosure flaw rather than an unauthenticated remote attack. This discrepancy between the assigned vector and the described mechanism is the most important signal for triage and should be verified against the vendor advisory before treating it as a network-exploitable vulnerability. In practice, risk is most acute in shared research computing environments, multi-user data science platforms, or containerized NLP pipelines where the FrameNet corpus directory is group- or world-writable while NLTK executes under a more privileged account. No EPSS data was included in the available intelligence, and the absence of a KEV listing combined with no identified public exploit code suggests exploitation has not been observed at scale. Confidentiality impact is real and high if the preconditions are met - the NLTK process can be made to read any XML file it has OS-level read access to - but the filesystem write prerequisite and XML-only output constraint limit practical blast radius in well-hardened deployments.

On a shared university NLP compute cluster where the FrameNet corpus directory is group-writable, a non-privileged researcher creates a symlink named 'attacker_frame' (no path separators) inside the corpus directory, pointing to a sensitive XML configuration file - such as a deployment config or credentials file - outside the corpus root. When an automated pipeline running under a more privileged service account subsequently calls frame_by_name('attacker_frame'), NLTK's path validation passes the separator-free name, the OS resolves the symlink at open-time, and the contents of the sensitive file are read as FrameNet corpus data and potentially surfaced to the attacker. No public proof-of-concept code has been identified, but the technique requires only standard Unix symlink creation.