CVE-2026-79676 in NLTK
Summary
by MITRE • 08/25/2026
NLTK versions before 3.10.3 contain a path traversal vulnerability in corpus readers that reopen root-derived paths using built-in open() instead of nltk.pathsec.open(), allowing symlinks to escape trusted roots. Attackers who stage symlinked corpus files under a trusted data root can disclose outside-root content through normal corpus reader methods like channels(), domains(), and synonyms().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The Natural Language Toolkit, commonly known as NLTK, is a widely used Python library for symbolic and statistical natural language processing. In versions prior to 3.10.3, the library contains a critical path traversal vulnerability within its corpus reader modules. This flaw stems from an inconsistent implementation of file access controls where certain operations rely on the standard built-in open() function rather than the security-hardened nltk.pathsec.open() method. The nltk.pathsec module is designed to enforce strict root-based path restrictions, ensuring that all file accesses remain confined within a designated trusted directory structure. By bypassing this mechanism in specific code paths, NLTK fails to validate whether the resolved file path remains within the allowed boundaries, thereby creating an opportunity for unauthorized access.
The technical nature of this vulnerability allows attackers to exploit symlinked files staged under a trusted data root. When corpus reader methods such as channels(), domains(), or synonyms() are invoked, they may resolve symbolic links without properly checking if the target of those links resides outside the permitted directory tree. Because the built-in open() function does not enforce the same security constraints as nltk.pathsec.open(), it permits reading files from arbitrary locations on the file system. This effectively neutralizes the intended isolation provided by the corpus reader architecture, allowing sensitive data stored in directories that should be inaccessible to be read and disclosed through normal API interactions.
The operational impact of this vulnerability is significant for applications relying on NLTK for processing untrusted or semi-trusted text corpora. An attacker with the ability to influence the file system structure, such as by placing symlinks within a directory monitored by an NLTK-based application, can extract confidential information from outside the trusted root. This could include configuration files, source code, credentials, or other sensitive data residing on the host machine. The vulnerability is particularly dangerous in server-side applications where corpus processing occurs automatically based on user input or scheduled tasks, as it enables remote attackers to perform unauthorized file reads without needing direct shell access or elevated privileges beyond what is required to create symlinks in accessible directories.
This flaw aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory and CWE-59: Improper Link Resolution Before File Access, as it involves the failure to properly validate symbolic links against security policies before performing file operations. From an ATT&CK perspective, this vulnerability facilitates Data from Local System via T1083, where attackers extract data directly from local files on a compromised system. The exploitation vector typically requires some level of filesystem interaction, making it relevant in scenarios involving web applications that process uploaded documents or internal tools handling external datasets.
To mitigate this risk, organizations should immediately upgrade NLTK to version 3.10.3 or later, where the path traversal issue has been addressed by ensuring consistent use of secure file opening mechanisms across all corpus reader methods. Additionally, developers implementing NLTK in production environments should enforce strict input validation and avoid processing untrusted corpora without sandboxing or chrooted environments that limit filesystem access further. Regular security audits of dependencies are essential to identify similar inconsistencies in how third-party libraries handle path resolution and symlink traversal.