CVE-2026-62385

NLTK 3.9.4's FrameNetCorpusReader (frame_by_name, doc, lu) and NKJPCorpusReader.header build XML filenames from caller-controlled selectors or trusted-looking index state without enforcing the corpus-root boundary, allowing path traversal. An attacker who can influence frame names, document filenames, LU ids, or NKJP file identifiers — or who can poison the fulltext index state — can cause NLTK to parse attacker-chosen XML files located outside the trusted corpus root and return that parsed content through normal reader responses. The practical gain is information disclosure: the CVSS 4.0 score of 8.2 assigns high confidentiality impact (no privilege or user interaction required, though attack complexity is high); integrity and availability are unaffected. Only applications that use these specific FrameNet or NKJP reader entrypoints in NLTK 3.9.4 and pass attacker-influenced inputs are affected; current source (v3.10.0-rc2) rejects the same payloads with explicit path-safety errors. There is no known public PoC, the issue is not in CISA KEV, and EPSS estimates a 0.4% probability of exploitation within 30 days, so no in-the-wild exploitation is currently known.

What to do: Upgrade to NLTK 3.10.0, which adds the path-safety rejections that keep these reader paths confined to the corpus root. If upgrading immediately, audit whether your application exposes frame_by_name, doc, lu, or NKJP header calls to attacker-influenced selectors or index state, and validate/sanitize path components there. Reference remediation follows the root-confinement model used by CorpusReader.open() and nltk.pathsec.