<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 23:30:31 +0000</lastBuildDate>
    <item>
      <title>BREW-acronym-CVE-2026-78681 — NLTK: Entity-expansion DoS (billion laughs) via remaining raw ElementTree parses</title>
      <link>https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-78681</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: acronym&lt;/p&gt;
&lt;p&gt;Several XML parsing sites in NLTK still used `xml.etree.ElementTree` directly, which honours `&amp;lt;!ENTITY&amp;gt;` declarations in a document&amp;#39;s internal DTD subset. A crafted document a few hundred bytes long can expand to megabytes in memory (each nesting level multiplies by ten), a denial-of-service.&lt;/p&gt;
&lt;p&gt;Affected call sites (&amp;lt;= 3.10.2):
- `nltk.chunk.named_entity.load_ace_file` — parses ACE annotation XML
- `nltk.internals.ElementWrapper` — converts any given string to an Element
- `nltk.downloader` — `Package.fromxml`, `Collection.fromxml`, `_find_collections`, `_find_packages`&lt;/p&gt;
&lt;p&gt;libexpat 2.6.0 added an input-amplification cap, but it only engages above an activation threshold (~8 MiB output) and depends on whichever libexpat the interpreter links; builds against older libexpat have no cap at all. External entities are not resolved by ElementTree, so this is a memory-amplification DoS (CWE-776), not XXE/file disclosure.&lt;/p&gt;
&lt;p&gt;This completes the earlier defusedxml adoption that these sites were missed by. Fix routes all of them through a new `nltk.xmlsec` module that refuses entity declarations, preferring `defusedxml` and falling back to a standard-library `xml.parsers.expat` pre-scan when defusedxml is absent.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration&lt;/p&gt;
&lt;p&gt;Reproducible PoC against a real affected entry point (`nltk.internals.ElementWrapper`). Every number below is captured output, not illustrative.&lt;/p&gt;
&lt;p&gt;### 1. The amplification (vulnerable path: raw `xml.etree.ElementTree`)&lt;/p&gt;
&lt;p&gt;A payload of a few hundred bytes e…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: acronym&lt;/p&gt;
&lt;p&gt;Several XML parsing sites in NLTK still used `xml.etree.ElementTree` directly, which honours `&amp;lt;!ENTITY&amp;gt;` declarations in a document&amp;#39;s internal DTD subset. A crafted document a few hundred bytes long can expand to megabytes in memory (each nesting level multiplies by ten), a denial-of-service.&lt;/p&gt;
&lt;p&gt;Affected call sites (&amp;lt;= 3.10.2):
- `nltk.chunk.named_entity.load_ace_file` — parses ACE annotation XML
- `nltk.internals.ElementWrapper` — converts any given string to an Element
- `nltk.downloader` — `Package.fromxml`, `Collection.fromxml`, `_find_collections`, `_find_packages`&lt;/p&gt;
&lt;p&gt;libexpat 2.6.0 added an input-amplification cap, but it only engages above an activation threshold (~8 MiB output) and depends on whichever libexpat the interpreter links; builds against older libexpat have no cap at all. External entities are not resolved by ElementTree, so this is a memory-amplification DoS (CWE-776), not XXE/file disclosure.&lt;/p&gt;
&lt;p&gt;This completes the earlier defusedxml adoption that these sites were missed by. Fix routes all of them through a new `nltk.xmlsec` module that refuses entity declarations, preferring `defusedxml` and falling back to a standard-library `xml.parsers.expat` pre-scan when defusedxml is absent.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration&lt;/p&gt;
&lt;p&gt;Reproducible PoC against a real affected entry point (`nltk.internals.ElementWrapper`). Every number below is captured output, not illustrative.&lt;/p&gt;
&lt;p&gt;### 1. The amplification (vulnerable path: raw `xml.etree.ElementTree`)&lt;/p&gt;
&lt;p&gt;A payload of a few hundred bytes e…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-78681</guid>
    </item>
    <item>
      <title>CVE-2026-78681 — NLTK before 3.10.3 Entity Expansion DoS via ElementTree</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-78681</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; nltk&lt;/p&gt;
&lt;p&gt;NLTK versions before 3.10.3 use xml.etree.ElementTree to parse XML in multiple modules, which honors entity declarations in document DTDs. Attackers can craft XML payloads with nested entity declarations that expand from hundreds of bytes to megabytes in memory, causing denial of service.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; nltk&lt;/p&gt;
&lt;p&gt;NLTK versions before 3.10.3 use xml.etree.ElementTree to parse XML in multiple modules, which honors entity declarations in document DTDs. Attackers can craft XML payloads with nested entity declarations that expand from hundreds of bytes to megabytes in memory, causing denial of service.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-78681</guid>
    </item>
    <item>
      <title>GHSA-97qj-x29f-37w7 — NLTK: Entity-expansion DoS (billion laughs) via remaining raw ElementTree parses</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-97qj-x29f-37w7</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: nltk&lt;/p&gt;
&lt;p&gt;Several XML parsing sites in NLTK still used `xml.etree.ElementTree` directly, which honours `&amp;lt;!ENTITY&amp;gt;` declarations in a document&amp;#39;s internal DTD subset. A crafted document a few hundred bytes long can expand to megabytes in memory (each nesting level multiplies by ten), a denial-of-service.&lt;/p&gt;
&lt;p&gt;Affected call sites (&amp;lt;= 3.10.2):
- `nltk.chunk.named_entity.load_ace_file` — parses ACE annotation XML
- `nltk.internals.ElementWrapper` — converts any given string to an Element
- `nltk.downloader` — `Package.fromxml`, `Collection.fromxml`, `_find_collections`, `_find_packages`&lt;/p&gt;
&lt;p&gt;libexpat 2.6.0 added an input-amplification cap, but it only engages above an activation threshold (~8 MiB output) and depends on whichever libexpat the interpreter links; builds against older libexpat have no cap at all. External entities are not resolved by ElementTree, so this is a memory-amplification DoS (CWE-776), not XXE/file disclosure.&lt;/p&gt;
&lt;p&gt;This completes the earlier defusedxml adoption that these sites were missed by. Fix routes all of them through a new `nltk.xmlsec` module that refuses entity declarations, preferring `defusedxml` and falling back to a standard-library `xml.parsers.expat` pre-scan when defusedxml is absent.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration&lt;/p&gt;
&lt;p&gt;Reproducible PoC against a real affected entry point (`nltk.internals.ElementWrapper`). Every number below is captured output, not illustrative.&lt;/p&gt;
&lt;p&gt;### 1. The amplification (vulnerable path: raw `xml.etree.ElementTree`)&lt;/p&gt;
&lt;p&gt;A payload of a few hundred bytes e…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: nltk&lt;/p&gt;
&lt;p&gt;Several XML parsing sites in NLTK still used `xml.etree.ElementTree` directly, which honours `&amp;lt;!ENTITY&amp;gt;` declarations in a document&amp;#39;s internal DTD subset. A crafted document a few hundred bytes long can expand to megabytes in memory (each nesting level multiplies by ten), a denial-of-service.&lt;/p&gt;
&lt;p&gt;Affected call sites (&amp;lt;= 3.10.2):
- `nltk.chunk.named_entity.load_ace_file` — parses ACE annotation XML
- `nltk.internals.ElementWrapper` — converts any given string to an Element
- `nltk.downloader` — `Package.fromxml`, `Collection.fromxml`, `_find_collections`, `_find_packages`&lt;/p&gt;
&lt;p&gt;libexpat 2.6.0 added an input-amplification cap, but it only engages above an activation threshold (~8 MiB output) and depends on whichever libexpat the interpreter links; builds against older libexpat have no cap at all. External entities are not resolved by ElementTree, so this is a memory-amplification DoS (CWE-776), not XXE/file disclosure.&lt;/p&gt;
&lt;p&gt;This completes the earlier defusedxml adoption that these sites were missed by. Fix routes all of them through a new `nltk.xmlsec` module that refuses entity declarations, preferring `defusedxml` and falling back to a standard-library `xml.parsers.expat` pre-scan when defusedxml is absent.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration&lt;/p&gt;
&lt;p&gt;Reproducible PoC against a real affected entry point (`nltk.internals.ElementWrapper`). Every number below is captured output, not illustrative.&lt;/p&gt;
&lt;p&gt;### 1. The amplification (vulnerable path: raw `xml.etree.ElementTree`)&lt;/p&gt;
&lt;p&gt;A payload of a few hundred bytes e…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-97qj-x29f-37w7</guid>
    </item>
  </channel>
</rss>
