Apache OpenNLP discloses two denial-of-service vulnerabilities (CVE-2026-67211, CVE-2026-82617), both fixed in 3.0.0-M6
Two Apache OpenNLP DoS flaws disclosed via oss-security on 2026-09-11: CVE-2026-67211 (out-of-memory via unbounded map pre-sizing in SymSpellModelSerializer, affecting opennlp-symspell 3.0.0-M4/M5) and CVE-2026-82617 (ReDoS/stack exhaustion via built-in EMAIL…
On 2026-09-11, two oss-security postings disclosed separate denial-of-service vulnerabilities in Apache OpenNLP. CVE-2026-67211 affects only the opennlp-symspell artifact in versions 3.0.0-M4 and 3.0.0-M5: the SymSpellModelSerializer.create() method performs unbounded map pre-sizing, allowing crafted input to trigger out-of-memory denial of service. Releases 1.x and 2.x are unaffected because the spellcheck extension was introduced in 3.0.0-M4; the issue is resolved in 3.0.0-M6. CVE-2026-82617 affects opennlp-core 3.0.0-M1 before 3.0.0-M6 and opennlp-tools 2.0.0 before 2.5.12: the DEFAULT_REGEX_NAME_FINDER.EMAIL and DEFAULT_REGEX_NAME_FINDER.URL patterns in RegexNameFinderFactory contain ambiguous nested quantifiers, so applications using these built-in finders on attacker-controlled input can be forced into regular expression denial of service or stack exhaustion. Fixes shipped in opennlp-tools 2.5.12 and opennlp-core 3.0.0-M6. Both vulnerabilities share the 3.0.0-M6 release as the fix point for the 3.x line.
- CVE-2026-67211: out-of-memory DoS via unbounded map pre-sizing in SymSpellModelSerializer.create()
- CVE-2026-67211 affects opennlp-symspell 3.0.0-M4 and 3.0.0-M5 only; 1.x and 2.x unaffected because the spellcheck extension was introduced in 3.0.0-M4
- CVE-2026-67211 fixed in opennlp-symspell 3.0.0-M6
- CVE-2026-82617: ReDoS and stack exhaustion via ambiguous nested quantifiers in the built-in DEFAULT_REGEX_NAME_FINDER.EMAIL and DEFAULT_REGEX_NAME_FINDER.URL patterns in RegexNameFinderFactory
- CVE-2026-82617 affects opennlp-core 3.0.0-M1 before 3.0.0-M6 and opennlp-tools 2.0.0 before 2.5.12
- CVE-2026-82617 exploitable when built-in regex finders process attacker-controlled input
- CVE-2026-82617 fixed in opennlp-tools 2.5.12 and opennlp-core 3.0.0-M6
- Both flaws fixed for the 3.x line in release 3.0.0-M6
Coverage timelineoldest first · each row is one article
- · 5d agoCVE-2026-67211: Apache OpenNLP: OOM DoS via Unbounded Array Allocation in SymSpellModelSerializer
oss-security· 24
Apache OpenNLP CVE-2026-67211: unbounded map pre-sizing in SymSpellModelSerializer enables out-of-memory denial of service in opennlp-symspell 3.0.0-M4/M5.
- · 5d agoCVE-2026-82617: Apache OpenNLP: ReDoS / stack exhaustion in RegexNameFinderFactory built-in EMAIL and URL patterns
Apache OpenNLP CVE-2026-82617: built-in EMAIL and URL regex name-finder patterns enable regular expression denial-of-service and stack exhaustion in affected releases.
Vulnerabilities in this storyAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-82617 +1 in the same advisory: …67211 | ReDoS in Apache OpenNLP built-in EMAIL and URL regex name finders CVE-2026-82617 is a regular-expression denial-of-service flaw (CWE-1333, inefficient regex complexity) in the two built-in name-finder patterns, EMAIL and URL, exposed by opennlp.tools.namefind.RegexNameFinderFactory in Apache OpenNLP. An application that obtains these finders via RegexNameFinderFactory.getDefaultRegexNameFinders(...) and applies them to untrusted text through RegexNameFinder.find(String[]) or find(String) can be driven into quadratic backtracking or unbounded matcher recursion by small crafted inputs: roughly 32 KB of text burns several seconds of CPU per EMAIL scan and returns no match, while roughly 4 KB of &-separated URL query tokens exhausts the thread stack and raises java.lang.StackOverflowError (about 1 KB suffices on worker threads with reduced stacks such as -Xss512k). Because no authentication or special configuration is needed, anyone who can control the text fed to these finders can convert each request into seconds to minutes of pinned CPU or abrupt thread death, denying service to the embedding application. Affected are applications embedding Apache OpenNLP 2.0.0 through 2.5.11 or 3.0.0-M1 through 3.0.0-M5 that have selected one of these two built-in finders; the flaw is specific to the built-in EMAIL/URL patterns and does not implicate model-based NER usage. There is no known exploitation, public proof-of-concept, or KEV listing as of now; fixed releases are 2.5.12 and 3.0.0-M6. Do: Upgrade to Apache OpenNLP 2.5.12, or to 3.0.0-M6 if you track the 3.0.0 milestone line, both of which fix the flaw. Until patched, avoid running the built-in EMAIL/URL finders from getDefaultRegexNameFinders() on untrusted input, or cap analyzed text to well under 1 KB on small-stack server worker threads and run find() on threads with larger stacks to prevent thread death. Audit whether your code path actually calls RegexNameFinder.find(String[])/find(String) with these default finders, since model-based NER usage is not implicated. | 10.0 group max | — |
| — |