CVE-2026-78681

NLTK (Natural Language Toolkit), a widely used Python NLP library distributed on PyPI, is vulnerable through version 3.10.2 to an XML entity-expansion ('billion laughs') denial-of-service (CWE-776) because several of its parsing sites still call xml.etree.ElementTree directly, which honors <!ENTITY> declarations in a document's internal DTD subset. An attacker who can control XML reaching the affected entry points — nltk.chunk.named_entity.load_ace_file, nltk.internals.ElementWrapper, or nltk.downloader's metadata parsing (Package.fromxml, Collection.fromxml, _find_collections, _find_packages) — submits a document of a few hundred bytes whose nested entities multiply tenfold per level into megabytes of memory (measured: 330 bytes expands to 1,000,000 bytes at five nesting levels). The only impact is availability — network-triggered with no privileges or user interaction required (CVSS 4.0: 8.7 High, VA:H) — via memory exhaustion or slowdown of the parsing process; there is no XXE file disclosure because ElementTree does not resolve external entities. Any environment running NLTK 3.10.2 or earlier that parses untrusted XML through these paths is affected; libexpat 2.6.0+'s built-in amplification cap is not a dependable mitigation because it engages only above ~8 MiB of expanded output and depends on the libexpat build the interpreter links, with older builds having no cap at all. No in-the-wild exploitation has been reported, no independent public PoC is catalogued, the flaw is not in CISA KEV, and EPSS assigns a 0.3% probability of exploitation within 30 days, though the advisory shows the amplification is trivially reproducible.

What to do: Upgrade NLTK to a release newer than 3.10.2 that routes all XML parsing through the new nltk.xmlsec module, which rejects entity declarations (preferring defusedxml with an expat pre-scan fallback); the advisory does not name the fixed version, so check the changelog for nltk.xmlsec. Until patched, avoid passing untrusted XML through the affected entry points (load_ace_file, ElementWrapper, and nltk.downloader metadata parsing), and do not rely on libexpat 2.6.0+'s amplification cap alone, since it engages only above ~8 MiB of expansion and older linked libexpat builds have no cap at all.