NLTK PorterStemmer EUVD-2026-67072

Exploitation requires that the target application calls NLTK's PorterStemmer.stem() on text that includes attacker-controlled tokens without enforcing a maximum token length. This is not a default-configuration attack against NLTK itself - NLTK is a library, not a standalone service, so exploitation depends entirely on how the application integrates it. The specific triggering condition is a single token of approximately 20,000-50,000 characters consisting predominantly of the letter 'y' followed by a recognized English suffix (e.g., 'ness', 'ly'). Applications that pre-tokenize input using standard whitespace splitting are still vulnerable if they do not cap individual token length. Limitations on exploitation: the attack requires network access to an endpoint that invokes PorterStemmer on user input; applications that only stem internal or pre-validated corpora are not exposed; and the impact is bounded to a single CPU core per request on multi-core systems with proper process isolation, which reduces but does not eliminate availability risk. Authentication requirements are not intrinsic to the vulnerability - they depend entirely on whether the exposing application requires authentication, which cannot be determined from library-level CVE data alone.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) scores 8.7, reflecting that the attack requires no authentication, no special network position, and no user interaction - consistent with the description. The pure availability impact (VC:N/VI:N) is accurate: there is no confidentiality or integrity consequence. The practical exploitability, however, is narrower than a raw CVSS reading suggests: the vulnerable code path is only reachable if the application pipes untrusted, unvalidated input directly into PorterStemmer.stem(), a non-default condition that requires a specific architectural decision by the application developer. Production NLP pipelines often do accept user-supplied text for stemming (search engines, text classifiers, chatbots), so the population of genuinely exposed services is real but not universal. EPSS data is not available in the provided intelligence, and the vulnerability is not listed in CISA KEV, meaning no confirmed active exploitation is on record. The attack payload is low-complexity to construct from the public description - a long string of 'y' characters plus a common English suffix - so the gap between theoretical and practical exploitability is small once an attacker identifies a vulnerable endpoint. Even a mid-sized IT team operating NLP-backed services should treat this as an urgent dependency update rather than a deferred maintenance item, given the trivial construction of the payload. No conflicting signals exist between available data sources; the primary uncertainty is whether a given deployment actually exposes the stemmer to user input.

An attacker identifies a public-facing web service that accepts free-text input (e.g., a search field, a text analysis API) backed by NLTK's PorterStemmer for term normalization. The attacker submits a single HTTP request containing a token of approximately 30,000 'y' characters followed by the suffix 'ness', causing PorterStemmer.stem() to enter a quadratic computation loop that pins a CPU core for tens of seconds. By sending a low volume of such requests - potentially as few as one per worker thread - the attacker can render the service unresponsive without any authentication. No exploit code needs to be obtained; the attack string is fully derivable from the public CVE description.