Source: apache-opennlp Version: 2.5.9-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerability was published for apache-opennlp. CVE-2026-82617[0]: | 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 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. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-82617 https://www.cve.org/CVERecord?id=CVE-2026-82617 [1] https://lists.apache.org/thread/spzhcxxszqdpppg70m1zz2l3mv29mhl3 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
