CVE-2026-62384
The vulnerability in NLTK's FramenetCorpusReader is a canonicalization failure: the code validates corpus file names by rejecting path separators, but never resolves symlinks before checking the resulting path. An attacker who can place a symlink in a corpus directory—something that happens trivially when processing downloaded datasets—can resolve that symlink to point outside the corpus root and read arbitrary files on the system. The fix in NLTK 3.10.2 likely adds os.path.realpath() or equivalent to resolve the actual file path before validation. This closes the immediate vector, but it exemplifies a recurring pattern: security boundaries defined on input representation rather than resolved state. Heartblead checked read length rather than buffer bounds; libssh checked packet length before authentication. Each patch fixes the specific exploitation vector without resolving the architectural error of validating the wrong primitive. What matters more than patching this one reader is recognizing what the boundary was ever protecting. NLTK's corpus directories were designed as organizational conveniences, not security perimeters. The assumption that "files within the corpus root are safe" collapsed the moment an attacker could place symlinks there—which is exactly what happens when processing untrusted datasets from HuggingFace, GitHub, or institutional data shares. Modern NLP pipelines pull corpus data automatically from sources that have no security relationship with the code consuming them. The deployment reality has outpaced the threat model embedded in the original code. The CVSS 7.5 rating treats this as a file-read primitive, but the realistic blast radius is larger. A symlink bypass reading a configuration file may expose S3 credentials, API keys, or model weights that enable lateral movement beyond the corpus directory. Research environments with shared NFS mounts, group-writable directories, and CI/CD pipelines fetching third-party datasets amplify the exposure. What to do: verify NLTK 3.10.2 is deployed, but more importantly, audit other corpus readers and data loaders in your dependency tree for the same pattern—validating names rather than resolved paths. Treat corpus directories from untrusted sources as potentially adversarial, not as safe boundaries. The fix for FramenetCorpusReader is necessary; the systemic review of data loading patterns throughout NLTK and similar libraries is where the real exposure lies.
Reviewed through automated stages and approved by a human before publication.