CVE-2026-0846

What it actually does

In nltk 3.9.2, nltk.util.filestring() opens the path it is given with no canonicalization, allowlist, or directory jail. Any caller-controlled string—absolute path or parent-directory traversal—becomes an arbitrary local file read. Impact is confidentiality only (no write or code execution). When the helper is reached from a network-facing API or similar untrusted interface, the read is remotely exploitable with no privileges or user interaction (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, C:H/I:N/A:N); otherwise it is a local disclosure issue.

Why it matters to the business

Services that feed user-supplied names or paths into this NLTK helper can leak source, configuration, credentials, and other secrets, leading to follow-on account compromise, privacy or compliance incidents, and incident-response cost. NLTK is a common NLP dependency, so chatbots, document pipelines, and data-science APIs are the typical blast radius. The issue is not in CISA KEV, is not tied to ransomware, has no public exploit maturity, and EPSS remains low (~0.0053 after a modest 30-day rise). Residual risk is therefore driven by how the function is used, not by mass exploitation. No fixed versions are listed more than six months after publication, so unpatched call sites stay exposed until code is changed or a vendor patch is applied.

How an attack unfolds

An attacker finds an application path—often a web API, batch job, or notebook service—that passes a filename, corpus name, or similar string into nltk.util.filestring(). They replace the expected relative name with an absolute path or a path that walks outside the intended data directory. The function opens that path and returns file contents to the caller. Stolen secrets or configuration are then reused against other systems. No login or user interaction is required when the interface is public. No named threat actors or campaigns are associated with this CVE, and there is no evidence of in-the-wild or ransomware use.

How to fix it

No fixed nltk versions are listed for this CVE. Stop passing untrusted input into nltk.util.filestring(); resolve and confine paths to an explicit allowlisted data directory (reject anything whose real path is outside that root) or replace the helper with application-controlled file I/O. Inventory all call sites and any wrappers that forward request parameters, uploaded names, or job arguments. Apply input validation at API boundaries as a compensating control. Upgrade nltk as soon as an official patched release is published and pin to that version.

How to confirm the fix worked

Search code and dependencies for nltk.util.filestring and nltk 3.9.2 (and any other unpatched 3.x line still in use). Confirm no user-controlled string reaches the function, or that a real-path allowlist rejects paths outside the intended directory. In a non-production check, verify that only expected in-tree files are readable and that out-of-tree paths fail closed. After a vendor patch is available, confirm the installed package version and re-run the same negative tests.

Typical attack path

1. Locate an application that accepts a filename, corpus, or similar string and passes it to nltk.util.filestring() without a path jail.
2. Submit an absolute or parent-directory path instead of an expected in-tree name.
3. Receive the targeted file’s contents in the response, error, or downstream processing.
4. Reuse disclosed secrets or configuration for further access.

How to detect it

There are no public exploits, named actors, or KEV/ransomware associations, so hunt for attempted or successful arbitrary reads rather than a known payload. Review application and API logs for requests whose filename, corpus, or path parameters are absolute or contain parent-directory segments, especially on endpoints that use NLTK. On hosts running Python services that import nltk, inspect auditd, Sysmon, EDR, or equivalent file-open telemetry for those processes reading sensitive locations (credential files, cloud metadata, application secrets, SSH keys) they do not normally touch. Correlate with tracebacks or debug logs mentioning nltk.util.filestring. Successful exploitation may leave no unique dropped files—look for the read itself and subsequent use of leaked credentials.

What your security team should do

• Immediately inventory production and CI uses of nltk.util.filestring and treat any user-influenced call as an information-disclosure finding.
• Block or wrap the function so only allowlisted, canonicalized paths under a data root are opened; do not wait for a package bump.
• Pin and upgrade nltk when a patched release exists; until then, restrict network exposure of any API that accepts file or corpus names.
• Enable application and host file-access auditing on services that import nltk so unexpected reads of secrets and config can be investigated.
• Reassess after patching: low EPSS and no KEV listing do not reduce the need to close reachable call sites.