CVE-2026-79674

NLTK's corpus-reader base constructor converts an attacker-influenced string root into a FileSystemPathPointer without any nltk.pathsec validation, so readers such as LinThesaurusCorpusReader and PanLexLiteCorpusReader call builtin open() and sqlite3.connect() directly on derived paths and never hit the sandbox guard that pathsec.open() enforces. An attacker who can supply or influence the corpus root path passed to these readers can make the process read files or SQLite databases outside the sanctioned data root even with pathsec ENFORCE=True, gaining access beyond the intended boundary (CVSS 4.0 rates confidentiality impact high and integrity impact low). Exposure is concentrated in deployments that rely on the nltk.pathsec sandbox as a security boundary and pass untrusted or user-controlled root paths to corpus readers; typical offline NLTK usage with self-managed corpora is not meaningfully affected. The flaw was verified in NLTK 3.10.2 (commit 474af1f5) on Python 3.13.14; no in-the-wild exploitation is known, it is not listed in CISA KEV, and EPSS assigns roughly a 0.2% probability of exploitation within 30 days.

What to do: Audit whether user- or externally controlled root paths reach NLTK corpus readers (especially LinThesaurusCorpusReader and PanLexLiteCorpusReader) while you rely on nltk.pathsec with ENFORCE=True, and canonicalize/validate roots against the sanctioned sandbox root before constructing readers. No fixed release is stated in the available data, so track NLTK's PyPI/GitHub for a patch adding pathsec validation to CorpusReader.__init__ and treat pathsec boundaries for these readers as bypassable until then; if you do not use pathsec sandboxing, this issue has little practical impact.