CVE-2026-81722

NLTK's PorterStemmer.stem() in versions up to and including 3.10.2 contains an inefficient-algorithmic-complexity flaw (CWE-407): the _is_consonant() helper walks backward over the entire run of trailing 'y' characters on every call, and _measure() invokes it for each stem position, producing O(n^2) behavior on a single token. An attacker who can submit one untrusted token of roughly 20-50 KB — e.g., a long run of the letter 'y' followed by a matching suffix such as 'ness' — can pin a CPU core for seconds to minutes. The impact is purely to availability: repeated or concurrent malicious tokens can exhaust CPU and stall or degrade a service, with no confidentiality or integrity impact. Any application or service running NLTK ≤ 3.10.2 that applies PorterStemmer to attacker-controlled text is affected, while offline or research use on trusted corpora is largely unaffected. Exploitation has not been observed in the wild (not in CISA KEV, EPSS ~0.4%), but a public security advisory with PoC reference (GHSA-ww6m-cw3f-q94g) exists and a fixed release, 3.10.3, is available.

What to do: Upgrade to NLTK 3.10.3 or later, which fixes the quadratic behavior in PorterStemmer. As interim mitigation, cap the length of untrusted tokens before stemming (e.g., reject or truncate single tokens above a few KB) or apply timeouts and rate limits around stemming of user input. Audit whether your services pass attacker-controlled text to PorterStemmer.stem() or related stemming entry points, and prioritize those for patching.