CVE-2026-62385 in NLTK
Summary
by MITRE • 08/22/2026
NLTK versions before 3.10.0 contain a path traversal vulnerability in FramenetCorpusReader and NKJPCorpusReader that allows attackers to parse XML files outside the corpus root by supplying unsafe selectors or poisoned index state. Attackers can exploit frame_by_name, doc, lu, and header methods with crafted parameters to read arbitrary XML files accessible to the application.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Natural Language Toolkit (NLTK) is a widely used Python library for symbolic and statistical natural language processing, providing easy-to-use interfaces to over fifty corpora and lexical resources such as WordNet. Within this ecosystem, corpus readers are responsible for loading data from various formats into memory structures that can be queried by application logic. Versions of NLTK prior to 3.10.0 contain a critical path traversal vulnerability affecting the FramenetCorpusReader and NKJPCorpusReader classes. This flaw arises because these components do not sufficiently validate or sanitize user-supplied selectors when constructing file paths for XML documents, allowing an attacker to manipulate directory navigation sequences to access files outside the intended corpus root directory.
The technical nature of this vulnerability is classified as a Path Traversal issue, which aligns with CWE-22 in the Common Weakness Enumeration standard. The core defect lies in how the frame_by_name, doc, lu, and header methods process input parameters. When an attacker supplies crafted selectors containing relative path traversal sequences such as dot-dot-slash patterns or encoded equivalents, the underlying file system operations resolve these paths incorrectly. Instead of restricting access to files within the designated corpus directory, the application resolves the path against the filesystem root or a parent directory, effectively bypassing security boundaries designed to isolate data sources. This behavior is particularly dangerous in scenarios where the NLTK library is integrated into web applications or services that process untrusted input as part of their normal operation.
The operational impact of this vulnerability extends beyond simple file reading. By exploiting these methods with poisoned index states or malicious selectors, an attacker can read arbitrary XML files accessible to the application running context. This capability enables unauthorized information disclosure, potentially exposing sensitive configuration files, internal documentation, credentials stored in plaintext within corpus data, or other critical system resources depending on the permissions of the executing process. In a web service environment, this could lead to further exploitation vectors such as server-side request forgery if the read content is processed by subsequent parsers that are themselves vulnerable to injection attacks. The ability to traverse directories undermines the integrity and confidentiality guarantees expected from isolated data processing pipelines.
Mitigation strategies for organizations relying on NLTK involve immediate version upgrades to 3.10.0 or later, where these path validation mechanisms have been hardened. For environments unable to upgrade immediately, defensive coding practices should be implemented by wrapping corpus reader calls with explicit path normalization and verification logic that ensures the resolved file path remains within the expected base directory. Input sanitization at the application layer is also recommended to strip any non-alphanumeric characters or traversal sequences before they reach the NLTK methods. Security teams should audit existing codebases for direct usage of FramenetCorpusReader and NKJPCorpusReader with user-controlled inputs, as these represent high-risk attack surfaces in data-intensive applications.
From a threat intelligence perspective, this vulnerability can be mapped to ATT&CK technique T1083, which covers File and Directory Discovery, specifically the aspect of accessing files outside of expected directories. Attackers leveraging this flaw would likely use it during the initial access or discovery phases to gather information about the host system's file structure. The exploitation does not require authentication if the vulnerable endpoint is exposed publicly, making it a significant risk for internet-facing services that utilize NLTK for text processing tasks involving FrameNet or NKJP corpora. Regular vulnerability scanning and dependency management processes are essential to detect such outdated library versions before they can be exploited in production environments.