Critical [CVE-2026-82617] Apache OpenNLP: 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

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 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

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