CVE-2026-82617: Apache OpenNLP: ReDoS / stack exhaustion in RegexNameFinderFactory built-in EMAIL and URL patterns

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.