https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 12:46:11 +0000 https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-54293 <p><strong>Affected:</strong> Homebrew: acronym</p> <p>### Summary nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. ### Affected Component nltk/data.py — find(), normalize_resource_url(), and the _UNSAFE_NO_PROTOCOL_RE regex check. Relevant occurrences:</p> <p>data.py L650–L653 — final path constructed from url2pathname(resource_name) after checks data.py L54–L69 — _UNSAFE_NO_PROTOCOL_RE operates only on the undecoded string data.py L219–L245 — normalize_resource_url() for nltk: scheme contributes to decode-after-check data.py L615–L618 — defense-in-depth traversal check also operates on undecoded input</p> <p>Root Cause The regex _UNSAFE_NO_PROTOCOL_RE is matched against the raw resource string. Path normalization via url2pathname() happens later, so any percent-encoded / (%2f) or . (%2e) is invisible to the regex but becomes active in the final path. ### Proof of Concept ``` &#34;&#34;&#34; NLTK Arbitrary File Read via URL-Encoded Path Traversal ======================…</p> <p><strong>Affected:</strong> Homebrew: acronym</p> <p>### Summary nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. ### Affected Component nltk/data.py — find(), normalize_resource_url(), and the _UNSAFE_NO_PROTOCOL_RE regex check. Relevant occurrences:</p> <p>data.py L650–L653 — final path constructed from url2pathname(resource_name) after checks data.py L54–L69 — _UNSAFE_NO_PROTOCOL_RE operates only on the undecoded string data.py L219–L245 — normalize_resource_url() for nltk: scheme contributes to decode-after-check data.py L615–L618 — defense-in-depth traversal check also operates on undecoded input</p> <p>Root Cause The regex _UNSAFE_NO_PROTOCOL_RE is matched against the raw resource string. Path normalization via url2pathname() happens later, so any percent-encoded / (%2f) or . (%2e) is invisible to the regex but becomes active in the final path. ### Proof of Concept ``` &#34;&#34;&#34; NLTK Arbitrary File Read via URL-Encoded Path Traversal ======================…</p> https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-54293 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1094 certfr-2026-avi-1094 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1094 https://cve.radiocsirt.org/vuln/euvd-2026-365485 EUVD-2026-365485 https://cve.radiocsirt.org/vuln/euvd-2026-365485 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54293 <p>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</p> <p>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54293 https://cve.radiocsirt.org/vuln/ghsa-p4gq-832x-fm9v <p><strong>Affected:</strong> PyPI: nltk</p> <p>### Summary nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. ### Affected Component nltk/data.py — find(), normalize_resource_url(), and the _UNSAFE_NO_PROTOCOL_RE regex check. Relevant occurrences:</p> <p>data.py L650–L653 — final path constructed from url2pathname(resource_name) after checks data.py L54–L69 — _UNSAFE_NO_PROTOCOL_RE operates only on the undecoded string data.py L219–L245 — normalize_resource_url() for nltk: scheme contributes to decode-after-check data.py L615–L618 — defense-in-depth traversal check also operates on undecoded input</p> <p>Root Cause The regex _UNSAFE_NO_PROTOCOL_RE is matched against the raw resource string. Path normalization via url2pathname() happens later, so any percent-encoded / (%2f) or . (%2e) is invisible to the regex but becomes active in the final path. ### Proof of Concept ``` &#34;&#34;&#34; NLTK Arbitrary File Read via URL-Encoded Path Traversal ======================…</p> <p><strong>Affected:</strong> PyPI: nltk</p> <p>### Summary nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. ### Affected Component nltk/data.py — find(), normalize_resource_url(), and the _UNSAFE_NO_PROTOCOL_RE regex check. Relevant occurrences:</p> <p>data.py L650–L653 — final path constructed from url2pathname(resource_name) after checks data.py L54–L69 — _UNSAFE_NO_PROTOCOL_RE operates only on the undecoded string data.py L219–L245 — normalize_resource_url() for nltk: scheme contributes to decode-after-check data.py L615–L618 — defense-in-depth traversal check also operates on undecoded input</p> <p>Root Cause The regex _UNSAFE_NO_PROTOCOL_RE is matched against the raw resource string. Path normalization via url2pathname() happens later, so any percent-encoded / (%2f) or . (%2e) is invisible to the regex but becomes active in the final path. ### Proof of Concept ``` &#34;&#34;&#34; NLTK Arbitrary File Read via URL-Encoded Path Traversal ======================…</p> https://cve.radiocsirt.org/vuln/ghsa-p4gq-832x-fm9v https://cve.radiocsirt.org/vuln/opensuse-su-2026:11098-1 <p>python311-nltk-3.10.0rc1-1.1 on GA media</p> <p>python311-nltk-3.10.0rc1-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11098-1 https://cve.radiocsirt.org/vuln/pysec-2026-2078 <p><strong>Affected:</strong> PyPI: nltk</p> <p>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</p> <p><strong>Affected:</strong> PyPI: nltk</p> <p>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</p> https://cve.radiocsirt.org/vuln/pysec-2026-2078 https://cve.radiocsirt.org/vuln/rhsa-2026:42644 <p>idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded transformers: code execution when processing a malicious Perceiver model file transformers: code execution when processing a malicious Transformer-XL model file transformers: code execution when processing a malicious megatron_gpt2 model file transformers: code execution when converting a malicious SEW model checkpoint transformers: code execution when converting a malicious SEW-D model checkpoint transformers: code execution when converting a malicious HuBERT model checkpoint transformers: code execution when processing a malicious X-CLIP model file transformers: code execution when processing a malicious GLM4 model file aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request python-transformers: python-transformers: Arbitrary code execution due to overridden trust_remote_code setting python-pip: Path traversal via malicious entry point name in pip wheel installation allows arbitrary file overwrite keras: Keras: Arbitrary file write via path traversal in archive extraction utilities vllm: vLLM: Denial of Service via specially crafted image in multimodal model serving vLLM: vLLM: Arbitrary code execution via untrusted model loading pyasn1: pyasn1: Denial of Service due to memory exhaustion from malformed RELATIVE-OID python-multipart: Python-Multipart: Arbitrary file write via path traversal vulne…</p> <p>idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded transformers: code execution when processing a malicious Perceiver model file transformers: code execution when processing a malicious Transformer-XL model file transformers: code execution when processing a malicious megatron_gpt2 model file transformers: code execution when converting a malicious SEW model checkpoint transformers: code execution when converting a malicious SEW-D model checkpoint transformers: code execution when converting a malicious HuBERT model checkpoint transformers: code execution when processing a malicious X-CLIP model file transformers: code execution when processing a malicious GLM4 model file aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request python-transformers: python-transformers: Arbitrary code execution due to overridden trust_remote_code setting python-pip: Path traversal via malicious entry point name in pip wheel installation allows arbitrary file overwrite keras: Keras: Arbitrary file write via path traversal in archive extraction utilities vllm: vLLM: Denial of Service via specially crafted image in multimodal model serving vLLM: vLLM: Arbitrary code execution via untrusted model loading pyasn1: pyasn1: Denial of Service due to memory exhaustion from malformed RELATIVE-OID python-multipart: Python-Multipart: Arbitrary file write via path traversal vulne…</p> https://cve.radiocsirt.org/vuln/rhsa-2026:42644 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54293 <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:25.10: nltk, Ubuntu:Pro:26.04:LTS: nltk</p> <p>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</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:25.10: nltk, Ubuntu:Pro:26.04:LTS: nltk</p> <p>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK&#39;s SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54293