The vulnerability in NLTK's XMLCorpusView._read_xml_fragment() arises because the function reads a corpus file in 1 KiB blocks, appending each block to a growing string fragment. On each iteration, it calls a regex match on the entire accumulated fragment, causing the total work to grow quadratically with input size. For malformed XML inputs that never match the regex, the loop continues until EOF, resulting in excessive CPU consumption. This affects readers such as BNCCorpusReader and others relying on XMLCorpusView, but not XMLCorpusReader.xml(). The issue was verified in NLTK versions 3.9.4, 3.10.0, and the current development branch. No patch exists in published releases, but a fix is proposed to use incremental parsing or bounded fragment accumulation to eliminate the quadratic behavior.

Applications processing attacker-controlled XML corpus files with affected NLTK readers can experience CPU exhaustion leading to denial of service. The attacker only needs write access to a file path the reader will open; no special privileges or credentials are required. Offline tools processing trusted local corpora are not at risk. The impact is limited to availability (denial of service) with no confidentiality or integrity impact.

A patch is available for this vulnerability. Users should apply the official fix once released. Until then, avoid processing untrusted XML corpus files with affected readers. The suggested fix involves avoiding rescanning the entire accumulated fragment on each iteration by using incremental parsing or bounded fragment accumulation. No generic mitigations are recommended beyond applying the patch when available.