https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 12 Nov 2026 07:24:57 +0000 https://db.gcve.eu/vuln/brew-acronym-cve-2026-12074 <p><strong>Affected:</strong> Homebrew: acronym</p> <p>### Summary `FramenetCorpusReader.frame(name)` interpolates a caller-supplied frame name into an XML file path that is read with the builtin `open()`, bypassing `CorpusReader.open()` and the `nltk.pathsec` sandbox — including strict `ENFORCE=True` mode. A `../` sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller.</p> <p>### Details `frame_by_name` builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed `.xml` extension, with no containment check, then constructs an `XMLCorpusView` from that **string** path. Because the view is built from a string rather than a `PathPointer`, it reads with the builtin `open()`, so `nltk.pathsec.validate_path()` is never invoked and `ENFORCE=True` does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; `frame_by_name` never goes through `CorpusReader.open()`, so that protection does not apply.</p> <p>The same string-path-into-`XMLCorpusView` pattern exists in two sibling methods that take a name from corpus data rather than the immediate caller: - `doc()` — uses the index entry `filename` field - the lexical-unit file loader — uses the `lexUnit` ID attribute</p> <p>These are reachable through a malicious or attacker-modified FrameNet corpus index.</p> <p>### PoC ```python &#34;&#34;&#34;</p> <p>import os import sys import tempfile import warnings from pathlib import Path</p> <p>warnings.filterwarnings(&#34;i…</p> <p><strong>Affected:</strong> Homebrew: acronym</p> <p>### Summary `FramenetCorpusReader.frame(name)` interpolates a caller-supplied frame name into an XML file path that is read with the builtin `open()`, bypassing `CorpusReader.open()` and the `nltk.pathsec` sandbox — including strict `ENFORCE=True` mode. A `../` sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller.</p> <p>### Details `frame_by_name` builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed `.xml` extension, with no containment check, then constructs an `XMLCorpusView` from that **string** path. Because the view is built from a string rather than a `PathPointer`, it reads with the builtin `open()`, so `nltk.pathsec.validate_path()` is never invoked and `ENFORCE=True` does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; `frame_by_name` never goes through `CorpusReader.open()`, so that protection does not apply.</p> <p>The same string-path-into-`XMLCorpusView` pattern exists in two sibling methods that take a name from corpus data rather than the immediate caller: - `doc()` — uses the index entry `filename` field - the lexical-unit file loader — uses the `lexUnit` ID attribute</p> <p>These are reachable through a malicious or attacker-modified FrameNet corpus index.</p> <p>### PoC ```python &#34;&#34;&#34;</p> <p>import os import sys import tempfile import warnings from pathlib import Path</p> <p>warnings.filterwarnings(&#34;i…</p> https://db.gcve.eu/vuln/brew-acronym-cve-2026-12074 https://db.gcve.eu/vuln/certfr-2026-avi-1486 certfr-2026-avi-1486 https://db.gcve.eu/vuln/certfr-2026-avi-1486 https://db.gcve.eu/vuln/ghsa-xh95-f55m-82fw <p><strong>Affected:</strong> PyPI: nltk</p> <p>### Summary `FramenetCorpusReader.frame(name)` interpolates a caller-supplied frame name into an XML file path that is read with the builtin `open()`, bypassing `CorpusReader.open()` and the `nltk.pathsec` sandbox — including strict `ENFORCE=True` mode. A `../` sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller.</p> <p>### Details `frame_by_name` builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed `.xml` extension, with no containment check, then constructs an `XMLCorpusView` from that **string** path. Because the view is built from a string rather than a `PathPointer`, it reads with the builtin `open()`, so `nltk.pathsec.validate_path()` is never invoked and `ENFORCE=True` does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; `frame_by_name` never goes through `CorpusReader.open()`, so that protection does not apply.</p> <p>The same string-path-into-`XMLCorpusView` pattern exists in two sibling methods that take a name from corpus data rather than the immediate caller: - `doc()` — uses the index entry `filename` field - the lexical-unit file loader — uses the `lexUnit` ID attribute</p> <p>These are reachable through a malicious or attacker-modified FrameNet corpus index.</p> <p>### PoC ```python &#34;&#34;&#34;</p> <p>import os import sys import tempfile import warnings from pathlib import Path</p> <p>warnings.filterwarnings(&#34;i…</p> <p><strong>Affected:</strong> PyPI: nltk</p> <p>### Summary `FramenetCorpusReader.frame(name)` interpolates a caller-supplied frame name into an XML file path that is read with the builtin `open()`, bypassing `CorpusReader.open()` and the `nltk.pathsec` sandbox — including strict `ENFORCE=True` mode. A `../` sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller.</p> <p>### Details `frame_by_name` builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed `.xml` extension, with no containment check, then constructs an `XMLCorpusView` from that **string** path. Because the view is built from a string rather than a `PathPointer`, it reads with the builtin `open()`, so `nltk.pathsec.validate_path()` is never invoked and `ENFORCE=True` does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; `frame_by_name` never goes through `CorpusReader.open()`, so that protection does not apply.</p> <p>The same string-path-into-`XMLCorpusView` pattern exists in two sibling methods that take a name from corpus data rather than the immediate caller: - `doc()` — uses the index entry `filename` field - the lexical-unit file loader — uses the `lexUnit` ID attribute</p> <p>These are reachable through a malicious or attacker-modified FrameNet corpus index.</p> <p>### PoC ```python &#34;&#34;&#34;</p> <p>import os import sys import tempfile import warnings from pathlib import Path</p> <p>warnings.filterwarnings(&#34;i…</p> https://db.gcve.eu/vuln/ghsa-xh95-f55m-82fw https://db.gcve.eu/vuln/pysec-2026-3584 <p><strong>Affected:</strong> PyPI: nltk</p> <p>### Summary `FramenetCorpusReader.frame(name)` interpolates a caller-supplied frame name into an XML file path that is read with the builtin `open()`, bypassing `CorpusReader.open()` and the `nltk.pathsec` sandbox — including strict `ENFORCE=True` mode. A `../` sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller.</p> <p>### Details `frame_by_name` builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed `.xml` extension, with no containment check, then constructs an `XMLCorpusView` from that **string** path. Because the view is built from a string rather than a `PathPointer`, it reads with the builtin `open()`, so `nltk.pathsec.validate_path()` is never invoked and `ENFORCE=True` does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; `frame_by_name` never goes through `CorpusReader.open()`, so that protection does not apply.</p> <p>The same string-path-into-`XMLCorpusView` pattern exists in two sibling methods that take a name from corpus data rather than the immediate caller: - `doc()` — uses the index entry `filename` field - the lexical-unit file loader — uses the `lexUnit` ID attribute</p> <p>These are reachable through a malicious or attacker-modified FrameNet corpus index.</p> <p>### PoC ```python &#34;&#34;&#34;</p> <p>import os import sys import tempfile import warnings from pathlib import Path</p> <p>warnings.filterwarnings(&#34;i…</p> <p><strong>Affected:</strong> PyPI: nltk</p> <p>### Summary `FramenetCorpusReader.frame(name)` interpolates a caller-supplied frame name into an XML file path that is read with the builtin `open()`, bypassing `CorpusReader.open()` and the `nltk.pathsec` sandbox — including strict `ENFORCE=True` mode. A `../` sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller.</p> <p>### Details `frame_by_name` builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed `.xml` extension, with no containment check, then constructs an `XMLCorpusView` from that **string** path. Because the view is built from a string rather than a `PathPointer`, it reads with the builtin `open()`, so `nltk.pathsec.validate_path()` is never invoked and `ENFORCE=True` does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; `frame_by_name` never goes through `CorpusReader.open()`, so that protection does not apply.</p> <p>The same string-path-into-`XMLCorpusView` pattern exists in two sibling methods that take a name from corpus data rather than the immediate caller: - `doc()` — uses the index entry `filename` field - the lexical-unit file loader — uses the `lexUnit` ID attribute</p> <p>These are reachable through a malicious or attacker-modified FrameNet corpus index.</p> <p>### PoC ```python &#34;&#34;&#34;</p> <p>import os import sys import tempfile import warnings from pathlib import Path</p> <p>warnings.filterwarnings(&#34;i…</p> https://db.gcve.eu/vuln/pysec-2026-3584 https://db.gcve.eu/vuln/ubuntu-cve-2026-12074 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: nltk, Ubuntu:Pro:16.04:LTS: nltk, Ubuntu:Pro:18.04:LTS: nltk, Ubuntu:Pro:20.04:LTS: nltk, Ubuntu:Pro:22.04:LTS: nltk, Ubuntu:Pro:24.04:LTS: nltk, Ubuntu:26.10: nltk, Ubuntu:Pro:26.04:LTS: nltk</p> <p>[Unknown description]</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: nltk, Ubuntu:Pro:16.04:LTS: nltk, Ubuntu:Pro:18.04:LTS: nltk, Ubuntu:Pro:20.04:LTS: nltk, Ubuntu:Pro:22.04:LTS: nltk, Ubuntu:Pro:24.04:LTS: nltk, Ubuntu:26.10: nltk, Ubuntu:Pro:26.04:LTS: nltk</p> <p>[Unknown description]</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-12074