<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T12:22:59.782675+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-54293</id>
    <title>BREW-acronym-CVE-2026-54293 — Natural Language Toolkit (NLTK): URL-Encoded Path Traversal in nltk.data.load() Allows Arbitrary Local File Read</title>
    <updated>2026-10-02T12:22:59.785803+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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'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
```
"""
NLTK Arbitrary File Read via URL-Encoded Path Traversal
======================…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-54293"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-54293</id>
    <title>CVE-2026-54293 — NLTK: URL-Encoded Path Traversal in nltk.data.load() Allows Arbitrary Local File Read</title>
    <updated>2026-10-02T12:22:59.785889+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> nltk, Red Hat OpenShift AI 2.25, Red Hat OpenShift AI 3.4, Red Hat Exploit Intelligence, Red Hat OpenShift Lightspeed, Red Hat Ansible Automation Platform 2, Red Hat OpenShift AI (RHOAI)</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'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></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-54293"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-p4gq-832x-fm9v</id>
    <title>GHSA-p4gq-832x-fm9v — Natural Language Toolkit (NLTK): URL-Encoded Path Traversal in nltk.data.load() Allows Arbitrary Local File Read</title>
    <updated>2026-10-02T12:22:59.785939+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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'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
```
"""
NLTK Arbitrary File Read via URL-Encoded Path Traversal
======================…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-p4gq-832x-fm9v"/>
  </entry>
</feed>
