CVE-2026-65915

NLTK versions before 3.10.0 contain a logic bug in FileSystemPathPointer.open() in which the sandbox validation check compares a normalized path against itself, so the check always passes and the security control is permanently inert (CWE-284, improper access control). The flaw is triggered when an application passes attacker-controlled input, such as a crafted file:// URL, to nltk.data.load(), allowing the loader to be pointed at any location on the host. An attacker gains arbitrary file read with the privileges of the process, enough to steal credentials and configuration files; the CVSS 4.0 vector confirms high confidentiality impact with no integrity or availability impact. Any Python (pip) project embedding NLTK prior to 3.10.0 is affected, but exploitation requires that untrusted paths or URLs actually reach the data-loading API. No confirmed in-the-wild exploitation is reported: a public advisory/PoC exists (GHSA-72r2-7mfr-5xr9), the CVE is not in CISA KEV, and EPSS estimates only about a 0.4% chance of exploitation in the next 30 days.

What to do: Upgrade to NLTK 3.10.0 or later (pip install -U nltk). Audit applications and dependencies for calls to nltk.data.load() and related data APIs that accept untrusted input, and until patched, reject or allowlist file:// URLs and paths rather than passing user-supplied values through. Given the low EPSS score and absence from CISA KEV, there is no evidence of mass exploitation, but prioritize internet-facing services that load user-supplied data paths.