CVE-2026-0847

What it actually does

NLTK through 3.9.2 fails to sanitize file and corpus paths in multiple CorpusReader classes (including WordListCorpusReader, TaggedCorpusReader, and BracketParseCorpusReader). An attacker who can influence those path arguments can traverse out of the intended corpus directory and read arbitrary files the process can open. The direct impact is confidentiality-only (CVSS 7.5, C:H/I:N/A:N): contents of configuration, credentials, keys, and other local files may be returned, logged, or otherwise exposed. This CVE does not itself write files or execute code; remote code execution would require a separate bug or misuse of stolen secrets.

Why it matters to the business

Chatbots, ML APIs, and NLP pipelines that pass user-influenced paths into NLTK can leak API tokens, SSH keys, cloud credentials, and other secrets, enabling account takeover or follow-on incidents. NLTK is a common Python NLP dependency, so any service that loads corpora from request data is in scope. Urgency is moderate rather than emergency: EPSS is low and flat (~0.009 over 30 days), the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none—but the advisory has been public for over 200 days with no fixed version listed in this dataset, so unpatched internet-facing NLP services remain an unnecessary secret-disclosure risk.

How an attack unfolds

An attacker finds an application that constructs or forwards a file, root, or corpus location into an NLTK CorpusReader. They supply a location that escapes the intended data directory. Because the reader does not adequately validate the resolved path, the worker process opens a file outside the corpus tree and the application reflects, logs, or otherwise exposes the contents. No named threat actors or ransomware campaigns are associated with this CVE, and there is no public exploit maturity; opportunistic probing of NLP and document-ingest APIs is the realistic scenario, not a tracked APT playbook. Stolen material (tokens, keys, configs) could later be reused against other systems, which is a consequence of the leak rather than a capability of this bug alone.

How to fix it

This dataset lists no official fixed NLTK version. Treat all nltk packages at or below 3.9.2 as affected: upgrade to a vendor-patched release from the official index as soon as one is published, then pin that version. Until a patch is available, do not pass user-controlled strings into CorpusReader path, root, or file arguments; resolve and constrain paths to an allowlisted corpus directory and reject any path that is not a child of that directory after canonicalization. Run NLP workers with least privilege, no read access to secrets or host key material, and filesystem isolation (separate user, container, or sandbox). Prefer shipping corpora as application assets rather than loading caller-specified files.

How to confirm the fix worked

Inventory every Python environment for nltk 3.9.2 or earlier. Search application code for WordListCorpusReader, TaggedCorpusReader, BracketParseCorpusReader, and any user-influenced root/file/corpus arguments. After upgrading, confirm the running interpreter reports a patched nltk version. Defensively verify that corpus loaders reject paths that resolve outside the allowlisted directory (assert denial/error, do not attempt to open sensitive host files). Confirm the service account cannot read secret locations even if a path were supplied. Re-scan dependencies on a regular cadence until an official fix is pinned.

Typical attack path

1. Identify an NLP, chatbot, or ML API that loads NLTK corpora or word/tag/parse files from request or upload input
2. Submit a corpus or file location intended to resolve outside the application's corpus directory
3. Cause WordListCorpusReader, TaggedCorpusReader, or BracketParseCorpusReader (or a subclass) to open that location
4. Recover file contents from the API response, error text, logs, or downstream pipeline output
5. Reuse any exposed credentials or keys against other services (follow-on activity, not this CVE)

How to detect it

There is no known in-the-wild exploit kit or named actor for this CVE, so hunt for opportunistic probing rather than a signatured campaign. Review web, API gateway, and application logs for corpus, file, root, or path parameters containing parent-directory sequences or absolute paths on NLP, chatbot, or document-ingest routes. Review Python application logs and stack traces that mention WordListCorpusReader, TaggedCorpusReader, or BracketParseCorpusReader together with unexpected file locations. On the host, inspect file-access audit logs (for example Linux auditd or equivalent process-file telemetry) for the NLP worker reading files outside the corpus data directory—especially configuration, key, and token files—around the time of those requests. Correlate with processes that import nltk. Absence of these artifacts does not prove non-exploitation if verbose logging was off.

• ../
• ..\
• %2e%2e%2f
• %2e%2e/
• %2e%2e%5c
• ..%2f
• WordListCorpusReader
• TaggedCorpusReader
• BracketParseCorpusReader

What your security team should do

• Inventory all services and images that ship nltk 3.9.2 or earlier, especially internet-facing ML/NLP APIs
• Stop passing request, upload, or other untrusted input into NLTK CorpusReader path arguments; enforce an allowlisted corpus root
• Upgrade nltk past 3.9.2 as soon as an official patched release exists and pin the version
• Restrict NLP worker filesystem permissions so the process cannot read secrets, keys, or host configuration
• Add WAF or application checks that reject parent-directory and absolute-path values on corpus/file parameters
• Hunt historical logs for traversal patterns on NLP ingest endpoints given 200+ days of public disclosure, even though EPSS and KEV risk are currently low