Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-22T15:16:18.833Z",
  "pubdate": "2026-08-22T15:16:18.833Z",
  "executiveSummary": "A path traversal vulnerability exists in versions of NLTK prior to 3.10.0, specifically impacting the FramenetCorpusReader and NKJPCorpusReader components.\nThe vulnerability allows remote or local threat actors to bypass corpus root directory boundaries and parse arbitrary XML files residing outside the intended directory structure.\nSuccessful exploitation results in unauthorized information disclosure, enabling attackers to read sensitive XML-formatted system files accessible to the application context.\nThe attack is executed by supplying crafted parameters, unsafe selectors, or poisoned index states into specific corpus reader methods.\nThe risk implication is moderate to high depending on file system permissions and the presence of sensitive data within the reach of the application's process privileges.\nPrerequisites for exploitation include application logic that processes untrusted inputs via vulnerable NLTK corpus reader interfaces without adequate input sanitization or path validation.",
  "technicalDetails": "The root cause of the vulnerability stems from insufficient input sanitization and lack of canonicalization checks within the FramenetCorpusReader and NKJPCorpusReader classes in NLTK versions before 3.10.0.\nWhen processing corpus data, these components improperly validate or restrict file paths derived from user-supplied arguments passed to specific methods.\nThe vulnerable components expose methods including frame_by_name, doc, lu, and header, which accept parameters that are subsequently utilized in file system path construction operations.\nAn attacker can exploit this flaw by injecting relative path traversal sequences (such as directory traversal patterns like dot-dot-slash) or by leveraging a poisoned index state.\nThe attack flow proceeds as follows: first, the adversary identifies an application entry point that passes untrusted user input directly into one of the vulnerable corpus reader methods (frame_by_name, doc, lu, or header). Second, the crafted parameter containing path traversal sequences is processed by the underlying reader implementation. Third, the component fails to restrict the resulting file path to the designated corpus root directory. Finally, the underlying file system API opens and parses the target XML file located outside the corpus root, returning data or error states that may expose the file contents.\nAffected versions comprise all NLTK releases preceding version 3.10.0.\nAuthentication and privilege requirements depend entirely on the host application architecture exposing the vulnerable NLTK methods, but the vulnerability itself requires no special privileges within the NLTK library.\nNetwork exposure is similarly determined by whether the vulnerable NLTK functionality is exposed via a network service, such as a web application or API processing natural language text.\nThe payload behavior involves supplying specially crafted strings to traversal-prone parameters to force the file reader to traverse upward in the directory hierarchy.\nThe post-exploitation impact centers on arbitrary file read capabilities, potentially exposing configuration files, source code, or other sensitive XML documents accessible to the running application process."
}