Cyber Resilience

CVE-2026-81722

DoS in Nltk ≤ 3.10.3

Public PoCDoS
Published
27 August 2026
Modified
31 August 2026
Patch / advisory
CVSS Score v4 8.7
Click a component to see what it means
Raw vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
EPSS Score 0.0036 30th percentile
Risk Priority 44 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2026-81722 is a high-severity Inefficient Algorithmic Complexity (CWE-407) vulnerability in Nltk Nltk. Its CVSS base score is 8.7 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 30th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.

The strongest mitigations our analysis identified map to SC-5 (Denial-of-service Protection) and SC-6 (Resource Availability) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

nltk PorterStemmer in versions <= 3.10.2 (fixed in 3.10.3) contains an inefficient-algorithmic-complexity denial of service in PorterStemmer.stem(). The _is_consonant() helper walks backward over the entire run of trailing 'y' characters on every call, and _measure() invokes it for each stem…

more

position, causing O(n^2) behavior. A single ~20-50 KB untrusted token consisting of a long run of the letter 'y' followed by a matching suffix (e.g., 'ness') can pin a CPU core for seconds to minutes, causing availability impact.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1499.003 Application Exhaustion Flood Impact
Adversaries may target resource intensive features of applications to cause a denial of service (DoS), denying availability to those applications.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-80206Same product: Nltk Nltk
CVE-2026-80205Same product: Nltk Nltk
CVE-2026-78681Same product: Nltk Nltk
CVE-2026-66393Same product: Nltk Nltk
CVE-2026-79657Same product: Nltk Nltk
CVE-2026-78682Same product: Nltk Nltk
CVE-2026-62385Same product: Nltk Nltk
CVE-2026-54293Same product: Nltk Nltk
CVE-2025-71408Same product: Nltk Nltk
CVE-2026-79676Same product: Nltk Nltk

Affected Assets

nltk
nltk
≤ 3.10.3

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V1.2.9

Mitigating Controls (NIST 800-53 r5) AI

Denial-of-service protection directly reduces the impact of resource exhaustion triggered by worst-case algorithmic inputs.

Resource availability allocation limits blast radius when an inefficient algorithm is forced into its worst case.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

DE.CM-09 partial match
prevents

Runtime monitoring of software and resources can detect the performance impact of triggered worst-case complexity.

ID.RA-01 partial match
prevents

Identifying and recording algorithmic-complexity vulnerabilities directly addresses the root cause before exploitation.

PR.PS-06 partial match
prevents

Secure SDLC practices (code review, complexity analysis, safe algorithm selection) prevent introduction of exploitable worst-case behavior.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

mitigates

Redundancy of processing facilities can absorb resource exhaustion from inefficient algorithms.

finds

Monitoring activities can identify anomalous resource consumption indicative of algorithmic complexity attacks.

prevents

Secure development life cycle includes design reviews that can catch inefficient algorithms before deployment.

prevents

Secure system architecture principles encourage selection of algorithms with acceptable worst-case complexity.

prevents

Secure coding practices can include guidelines to avoid or mitigate inefficient algorithms.

finds

Security testing can uncover performance issues stemming from algorithmic complexity.

References