Executive brief
NLTK's XML corpus reader rescans accumulated XML data repeatedly while processing large files, causing CPU consumption to grow quadratically with file size. An attacker who can supply a malformed XML corpus file can trigger severe CPU exhaustion and deny service to applications using affected corpus readers like BNCCorpusReader, with an 8 MB file consuming ~48 seconds of CPU on typical hardware.
Technical details
The vulnerability exists in XMLCorpusView._read_xml_fragment() (nltk/corpus/reader/xmldocs.py, lines 261–308), which reads XML corpus files in 1 KiB blocks and accumulates them into a fragment buffer. On each iteration, the function calls _VALID_XML_RE.match() on the entire accumulated buffer, causing O(N²) behavior where N is file size in KiB blocks. A malformed XML payload consisting of an unterminated opening tag (e.g., < followed by N bytes of 'a') will never match valid XML, forcing the loop to consume the entire file before EOF terminates it. Affected readers include BNCCorpusReader, NPSChatCorpusReader, SemcorCorpusReader, MTECorpusReader, NKJPCorpusReader, FrameNetCorpusReader, and VerbNetCorpusReader. The attack requires only write access to a path the reader will process; no authentication or special privileges are needed. NLTK 3.10.3 and later patch this issue; earlier versions including 3.9.4, 3.10.0, and 3.10.2 are vulnerable.
Affected products
- NLTK Project NLTK <= 3.10.2
Timeline
- 2026-08-12: disclosed: Original advisory GHSA-vp2x-qp44-57v7 published
- 2026: patched: Fixed in NLTK 3.10.3 or later
- 2026-08-27: advisory: Duplicate advisory GHSA-hqv3-xm29-p9hq published (later withdrawn)