Apache OpenNLP up to 2.5.11/3.0.0-M5 RegexNameFinder RegexNameFinderFactory.java RegexNameFinder.find String[] resource consumption

Summaryinfo

A vulnerability has been found in Apache OpenNLP up to 2.5.11/3.0.0-M5 and classified as problematic. Affected is the function RegexNameFinder.find of the file RegexNameFinderFactory.java of the component RegexNameFinder. Performing a manipulation of the argument String[] results in resource consumption. This vulnerability is cataloged as CVE-2026-82617. It is possible to initiate the attack remotely. There is no exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability classified as problematic has been found in Apache OpenNLP up to 2.5.11/3.0.0-M5. This affects the function RegexNameFinder.find of the file RegexNameFinderFactory.java of the component RegexNameFinder. The manipulation of the argument String[] with an unknown input leads to a resource consumption vulnerability. CWE is classifying the issue as CWE-400. The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. This is going to have an impact on availability. The summary by CVE is:

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.

The advisory is shared at lists.apache.org. This vulnerability is uniquely identified as CVE-2026-82617 since 08/30/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/11/2026). MITRE ATT&CK project uses the attack technique T1499 for this issue.

Upgrading to version 2.5.12 or 3.0.0-M6 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Vendor

• Apache

Name

• OpenNLP

Version

• 2.5.0
• 2.5.1
• 2.5.2
• 2.5.3
• 2.5.4
• 2.5.5
• 2.5.6
• 2.5.7
• 2.5.8
• 2.5.9
• 2.5.10
• 2.5.11
• 3.0.0-M5

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion