CVE-2026-126300: NLTK: Quadratic CPU exhaustion in TreebankWordTokenizer.span_tokenize via list.pop(0) in quote-restore loop

Summary

TreebankWordTokenizer.spantokenize in the NLTK tokenizer package contains an unguarded O(n^2) processing loop in its quote-restoration step. When the method is invoked on text containing a long run of double-quote characters (for example '"' n), it performs a list.pop(0) operation once per quote token, and because list.pop(0) is O(length), the total cost grows with the square of the input length. An attacker who can supply untrusted text to this public span-tokenization API can force a single request to saturate one CPU core for a prolonged period, degrading availability. No authentication, special configuration, or user interaction is required.

Root Cause

Inside spantokenize, when the input contains double or repeated quotes, the code builds matched, a list with one entry per quote occurrence, and then reconstructs tokens in a comprehension that calls matched.pop(0) for each token that is a quote. Removing the first element of a Python list is an O(len(list)) operation because all remaining elements are shifted. For an all-quote input the tokenizer produces n quote tokens and matched has n entries, so pop(0) is called n times, each time on a list of shrinking but still linear length, giving cumulative O(n^2) CPU work. The violated invariant is bounded per-input work: there is no length cap on spantokenize or the underlying tokenize, so untrusted input length translates into quadratic processing time. The neighboring aligntokens call is linear and is not the quadratic term.

text Affected function: TreebankWordTokenizer.spantokenize Source: nltk/tokenize/treebank.py - branch selector at line 203 - matched list built at line 205 - quadratic sink matched.pop(0) at line 209 - linear aligntokens call at line 215

Impact

An attacker who controls text passed to TreebankWordTokenizer.spantokenize can trigger quadratic CPU work. In the reviewed release, an all-quote input of 128,000 characters takes about 1.76 seconds and 256,000 characters about 6.57 seconds on a single core, with cost growing as the square of the length. Memory use is linear. The demonstrated capability is single-core CPU exhaustion producing denial of service or latency degradation in any network-reachable component that uses span tokenization on untrusted input, such as offset, annotation, or highlighting pipelines. There is no confidentiality or integrity impact. The plausible operational consequence, where multiple concurrent requests are used, is worker-pool exhaustion; this is inferred from the measured per-request cost and was not executed against a live deployment.

Proof of Concept

Requires only the released nltk package; no corpus download is needed.

1. Instantiate TreebankWordTokenizer. 2. Call spantokenize on an all-double-quote string of increasing length and time each call. 3. Compare against an equal-token-count control input that avoids the quote branch.

python import time from nltk.tokenize import TreebankWordTokenizer

tok = TreebankWordTokenizer() for n in (32000, 64000, 128000, 256000): payload = '"' n start = time.perfcounter() list(tok.spantokenize(payload)) print("quote-run", n, round(time.perfcounter() - start, 3))

control = "a " 128000 # comparable token count, avoids the pop(0) branch start = time.perfcounter() list(tok.spantokenize(control)) print("control", round(time.perfcounter() - start, 3))

text quote-run 32000 0.23 quote-run 64000 0.52 quote-run 128000 1.76 quote-run 256000 6.57 (about 4x per doubling => O(n^2)) control 0.16 (roughly 11x faster, isolates pop(0))

Attack Chain

1. Exposure: TreebankWordTokenizer is exported from nltk.tokenize and spantokenize is a public, documented method reachable by any service that span-tokenizes untrusted text. 2. Control: The attacker fully controls the text argument; a run of double-quote characters such as '"' n survives to the quote branch unchanged. 3. Path: The branch selector at line 203 ('"' in text or "''" in text) is satisfied by the payload, entering the vulnerable branch; matched is built at line 205 with n entries and the reconstruction comprehension runs at line 209. 4. Guard: There is no length cap on spantokenize or tokenize. The regex timeout backstop in nltk/redos.py only wraps regular-expression operations and does not cover the pure-Python list.pop(0) sink; a 256,000-character input ran to completion in 6.57 seconds with no timeout raised. 5. Primitive: matched.pop(0) executed once per quote token, each call O(len(matched)), yields cumulative O(n^2) CPU work. 6. Result: A single request with a large quote-run input exhausts one CPU core for a sustained period, degrading service availability.

Bypass Evidence

No guard blocks this path. Direct inspection found no MAXTOKENLEN or length check in nltk/tokenize/treebank.py, in contrast to the sibling sonoritysequencing.py which does cap token length. The strongest refutations were attempted and failed: (1) the hypothesis that tokenize collapses repeated quotes so few pop(0) calls occur was disproven by observing that tokenize('"' n) yields exactly n quote tokens and timing showing about 4x growth per doubling, while an equal-token-count non-quote control ran roughly 11x faster; (2) the hypothesis that the project regex-timeout backstop already caps this cost was disproven by running a 256,000-character input to normal completion in 6.57 seconds with no TimeoutError, confirming the backstop wraps only regex operations and not list.pop(0); (3) the hypothesis that this line was already audited was disproven, since the project quadratic-DoS test suite explicitly clears the neighboring aligntokens line reached through spantokenize but contains no test for the pop(0) loop, an audited-neighbor pattern where the adjacent line was checked and this one was missed. The seed remediation touched a different module and no advisory covers this sink.

Affected Versions

- Ecosystem: pip - Package: nltk - Confirmed affected range: >= 3.2.5, <= 3.10.3 - Latest release checked: 3.10.3 (PyPI) - Fix status: not fixed

The vulnerable pop(0) loop is present and unguarded in the current released artifact 3.10.3, verified by direct source inspection and by reproducing the quadratic curve through fresh execution. The lower bound of 3.2.5 reflects when the affected quote-restoration code shipped; the disclosure-relevant fact is that the latest published release is affected and no fix has been released.

Suggested Fix

Replace the O(n) list.pop(0) pattern with an O(1) consumption strategy, for example iterating over matched with an index or an iterator, or using collections.deque with popleft(), so that the quote-restoration step runs in linear time overall. Additionally, consider enforcing a configurable maximum input length in spantokenize consistent with the caps applied to sibling tokenizers, and ensure the fix covers all callers that pass untrusted text. As an interim mitigation, deployments that expose span tokenization of untrusted input can cap request and input sizes at the application boundary to bound the worst-case length.

Reported by zx (GitHub: @manus-pi).

Fix status (2026-09-28)

Two pull requests carry a fix.

PR: #3753 "[Do not merge yet] Fix GHSA-8mgp-746c-j5xp: URL-scheme bypass of pathsec.validatepath", open; head da55cab0e at the time of this note (a develop merge on top of 238f81500, the head on which the verdicts below were measured). Fix commit: cf12a5e6a (the quote-restore loop in tokenize/treebank.py and tokenize/destructive.py iterates forward instead of list.pop(0)).

PR: #3895 "[WIP] Bound algorithmic-DoS and uncontrolled-recursion vectors (CWE-400/407/674/1333)", open, head b22ebe144. Fix commit: e20c40e26 "Bound tokenizer/parser algorithmic DoS (ffr9/gpwc/8fx7)".

No probe. The advisory PoC re-run (spantokenize over 32k and 128k double quotes): #3753 head 3.5x over a 4x input, #3895 head 3.2x, both linear. On develop 2fa3f48fe the 128k run did not finish within 120 s, so develop is still VULNERABLE.