NLTK CVE-2026-81725

Exploitation requires that the target application use NLTK's Pl196xCorpusReader (specifically via words() or tagged_words() methods) AND that it processes attacker-supplied or attacker-influenced TEI corpus data. The CVSS 4.0 vector specifies AT:P (attack requirements present), meaning a precondition beyond mere network access exists: the application must be configured to accept external TEI input for processing. Default or academic NLTK deployments that load only bundled or internally trusted corpora are NOT exploitable. The impact is strictly a CPU-exhaustion denial of service-no authentication bypass, no data exfiltration, and no code execution is possible. Authentication requirements are not confirmed from the provided CVSS data (PR:N indicates no privilege required to invoke the API, not necessarily that the endpoint itself is unauthenticated at the application layer).

The CVSS 4.0 score of 6.3 reflects network reachability (AV:N) offset by high attack complexity (AC:H) and an attack prerequisite condition (AT:P), with impact limited entirely to availability at low severity (VA:L). There is no confidentiality or integrity impact. Real-world risk is conditional: only applications that pipe attacker-controlled TEI corpus content into Pl196xCorpusReader are exploitable. Deployments loading only trusted local corpora (the common academic use case) are not exposed. EPSS data was not provided in source intelligence. No CISA KEV listing exists and no POC code has been identified, suggesting this has not been actively weaponized at scale. The primary realistic concern is CPU starvation in shared or multi-tenant NLP API services. Despite the network vector, the combination of high complexity, attack prerequisites, and low availability impact makes this a moderate-not urgent-priority, warranting patching on a normal patch cycle rather than emergency response.

An attacker targeting an NLP-as-a-service application built on NLTK submits a crafted TEI corpus file containing thousands of nested, unmatched opening tags via the service's corpus analysis endpoint. The application calls words() on the uploaded corpus, triggering the vulnerable read_block regex which rescans the malformed block repeatedly, consuming near-quadratic CPU time relative to the tag depth and stalling or crashing the service worker. No POC code has been publicly identified, but the attack concept is straightforward given public documentation of ReDoS patterns.