CVE-2026-81723: NLTK XMLCorpusView quadratic CPU exhaustion

CVE-2026-81723 · Severity: low · CVSS 3.7 · Published 2026-08-27

NLTK is a Python natural language processing library widely used for corpus analysis and text processing. The XMLCorpusView component, which reads XML corpus files used for NLP tasks, has a performance flaw that allows an attacker with write access to a corpus file path to cause severe CPU exhaustion through a specially crafted malformed XML file. Processing an 8 MiB malformed file can consume ~48 CPU-seconds, potentially denying service to applications that rely on automated corpus processing.

Technologies: nltk (PyPI). Vendors: PyPI.

Quick answers

Is CVE-2026-81723 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-81723 being exploited in the wild.
How severe is CVE-2026-81723?
Low severity, with a CVSS score of 3.7, published 27 August 2026.
Which products and versions are affected?
nltk (PyPI) <= 3.10.2, ECOSYSTEM:introduced=0,fixed=3.10.3.
Is there a fix for CVE-2026-81723?
Yes. nltk (PyPI): upgrade to 3.10.3 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-81723 attacked?
It is attacked over the network.
Am I affected by CVE-2026-81723?
Check whether you run nltk (PyPI) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • nltk (PyPI): upgrade to 3.10.3 or later
    pip install "nltk>=3.10.3"

Technical details

The vulnerability is an algorithmic inefficiency in XMLCorpusView._read_xml_fragment() (nltk/corpus/reader/xmldocs.py, lines 261–308). The function reads XML corpus files in 1 KiB blocks, appending each block to a `fragment` string, then calls `_VALID_XML_RE.match(fragment)` to validate the accumulated buffer on every iteration. Because the regex match rescans the entire accumulated fragment from the beginning each iteration, total work grows O(n²) rather than O(n). For a payload of a single `<` followed by (N-1) `a` bytes, the unterminated tag prevents regex match success and `fragment.rfind("<")` returns 0, bypassing the backtrack optimization. The only exit is EOF after consuming all N bytes. This affects all readers derived from XMLCorpusView (BNCCorpusReader, NPSChatCorpusReader, SemcorCorpusReader, MTECorpusReader, NKJPCorpusReader, FrameNetCorpusReader, VerbNetCorpusReader) but not XMLCorpusReader.xml() which uses defusedxml.safe_parse(). Exploitation requires only write access to a corpus file path the reader will open; no authentication or special privileges are needed. A patch (NLTK 3.10.3+) is available that eliminates quadratic rescanning via incremental parsing or bounded accumulation.

Affected products

  • NLTK Project NLTK 3.10.2 and earlier; including 3.9.4, 3.10.0; potentially all versions since 2007 introduction of XMLCorpusView

Identifiers

  • CVE-2026-81723
  • GHSA-vp2x-qp44-57v7
  • PYSEC-2026-3871

Timeline

  • 2026-09-02: disclosed: Advisory published to GitHub Advisory Database and CVE
  • 2026-09-02: patched: NLTK 3.10.3 released with fix (commit 7808692)

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.