Cyber Resilience

CVE-2026-82617

Apache Opennlp 2.0.0 – 2.5.12

Published
11 September 2026
Modified
16 September 2026
Patch / advisory
CVSS Score v4 10.0
Click a component to see what it means
Raw vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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.0044 38th percentile
Risk Priority 47 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-82617 is a critical-severity Inefficient Regular Expression Complexity (CWE-1333) vulnerability in Apache Opennlp. Its CVSS base score is 10.0 (Critical).

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

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

The two built-in name-finder patterns exposed by opennlp.tools.namefind.RegexNameFinderFactory - DEFAULT_REGEX_NAME_FINDER.EMAIL and DEFAULT_REGEX_NAME_FINDER.URL - contain ambiguous nested quantifiers. An application that obtains these finders through RegexNameFinderFactory.getDefaultRegexNameFinders(...) and then applies them to untrusted text through RegexNameFinder.find(String[]) or RegexNameFinder.find(String) can be driven into…

more

super-linear backtracking or into unbounded matcher recursion by a small crafted input. For the EMAIL pattern, a long run of local-part characters that is never followed by an @ forces the matcher to re-scan to end-of-input from every starting offset. Cost grows quadratically with input length: an input of approximately 32 KB consumes several seconds of CPU in a single find() call and returns no match, and each doubling of the input multiplies the cost roughly four-fold. For the URL pattern, the query-string sub-expression nests a capturing repetition inside an outer repetition. The JDK matcher recurses once per query token, so an input of approximately 4 KB containing many &-separated tokens exhausts the thread stack and causes java.lang.StackOverflowError to propagate out of find(), terminating the calling thread. On a thread created with a smaller stack (for example -Xss512k, typical of server worker pools) approximately 1 KB is sufficient. In both cases an attacker who can supply text for analysis can convert a single request into seconds to minutes of pinned CPU, or into an abrupt thread death, denying service to the embedding application. No authentication, special configuration, or model file is required beyond the application having selected one of the two built-in finders. This issue affects Apache OpenNLP: from 2.0.0 through 2.5.11; from 3.0.0-M1 through 3.0.0-M5. Users are recommended to upgrade to version 2.5.12, or to 3.0.0-M6 for users tracking the 3.0.0 milestone line, which fix the issue.

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-2024-1963Shared CWE-1333
CVE-2026-60075Shared CWE-1333
CVE-2023-23621Shared CWE-1333
CVE-2026-0668Shared CWE-1333
CVE-2023-45806Shared CWE-1333
CVE-2026-33671Shared CWE-1333
CVE-2024-1736Shared CWE-1333
CVE-2025-43880Shared CWE-1333
CVE-2024-28865Shared CWE-1333
CVE-2024-2800Shared CWE-1333

Affected Assets

apache
opennlp
3.0.0 · 2.0.0 — 2.5.12

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation can discover inefficient regex patterns via performance or static analysis.

Development standards and tools can require safe regex construction and forbid known exponential patterns.

Denial-of-service protections limit resource exhaustion caused by expensive regex evaluation.

Input validation can constrain data that would otherwise trigger worst-case regex complexity.

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.

ID.RA-01 partial match
prevents

Vulnerability identification processes can discover ReDoS issues in existing code but do not stop their introduction.

PR.PS-06 partial match
prevents

Secure SDLC practices directly prevent inefficient regex via reviews, static analysis, and safe libraries.

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.

prevents

Secure development lifecycle mandates review of algorithmic efficiency, directly addressing ReDoS-prone regex.

prevents

Application security requirements can specify input-validation rules that limit regex complexity.

prevents

Secure architecture principles encourage avoidance of computationally expensive constructs such as catastrophic backtracking.

prevents

Secure coding standards explicitly prohibit or limit the use of inefficient regular expressions.

finds

Security testing can detect and reject regex patterns with exponential worst-case complexity.

References