CVE-2026-82617: Apache OpenNLP ReDoS DOS Vulnerability

CVE-2026-82617 Overview

Apache OpenNLP contains a regular expression denial of service (ReDoS) flaw in two built-in name-finder patterns exposed by RegexNameFinderFactory. The DEFAULT_REGEX_NAME_FINDER.EMAIL and DEFAULT_REGEX_NAME_FINDER.URL patterns contain ambiguous nested quantifiers. An attacker who supplies crafted text to an application calling RegexNameFinder.find() can trigger super-linear backtracking or unbounded matcher recursion. No authentication or model files are required. The result is pinned CPU for seconds to minutes, or an abrupt java.lang.StackOverflowError that terminates the calling thread.

Critical Impact
A single small crafted input can convert one request into sustained CPU exhaustion or thread death, denying service to any application using the built-in OpenNLP EMAIL or URL name finders.

Affected Products

Apache OpenNLP versions 2.0.0 through 2.5.11
Apache OpenNLP versions 3.0.0-M1 through 3.0.0-M5
Applications embedding opennlp.tools.namefind.RegexNameFinderFactory

Discovery Timeline

2026-09-11 - CVE-2026-82617 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-82617

Vulnerability Analysis

The flaw is a classic [CWE-1333] inefficient regular expression complexity issue affecting two built-in patterns retrieved through RegexNameFinderFactory.getDefaultRegexNameFinders(...). Both patterns use nested quantifiers that interact poorly with the JDK matcher.

The EMAIL pattern degrades quadratically. A long run of local-part characters not followed by an @ forces the matcher to re-scan to end-of-input from every starting offset. An input of roughly 32 KB consumes several seconds of CPU in a single find() call and returns no match. Each doubling of input length multiplies the cost roughly fourfold.

The URL pattern behaves differently. Its query-string sub-expression nests a capturing repetition inside an outer repetition. The JDK matcher recurses once per query token, so a roughly 4 KB input containing many &-separated tokens exhausts the thread stack. On worker pools using smaller stack sizes such as -Xss512k, approximately 1 KB is sufficient to trigger the overflow.

Root Cause

Both patterns contain ambiguous nested quantifiers that permit exponential or recursive matcher behavior on adversarial input. The EMAIL pattern lacks anchoring that would prune failed matches early. The URL pattern nests capturing repetition, causing recursive descent proportional to token count in the JDK regex engine.

Attack Vector

Any network-accessible application that ingests untrusted text and applies the built-in EMAIL or URL name finder is exploitable. The attacker submits a crafted string as normal input to an analysis endpoint. Exploitation requires no authentication, no special configuration, and no model files beyond the application selecting one of the two built-in finders. Result: pinned CPU or a StackOverflowError that kills the worker thread.

Detection Methods for CVE-2026-82617

Indicators of Compromise

Sudden CPU saturation on JVM worker threads correlated with text-analysis endpoints processing untrusted input.
java.lang.StackOverflowError entries in application logs originating from java.util.regex.Pattern$GroupTail.match or RegexNameFinder.find.
Repeated abnormal termination of worker threads in server pools processing user-supplied text.

Detection Strategies

Inventory application dependencies for apache:opennlp versions between 2.0.0 and 2.5.11 or 3.0.0-M1 through 3.0.0-M5 using software composition analysis.
Perform static code review for calls to RegexNameFinderFactory.getDefaultRegexNameFinders followed by RegexNameFinder.find.
Enable thread dump capture on OutOfMemoryError or StackOverflowError to attribute crashes to the vulnerable patterns.

Monitoring Recommendations

Alert on per-request CPU time exceeding baseline thresholds for text-processing endpoints.
Track JVM thread death rates and stack overflow exceptions in APM tooling.
Log request sizes and payload characteristics for endpoints invoking OpenNLP name finders.

How to Mitigate CVE-2026-82617

Immediate Actions Required

Upgrade Apache OpenNLP to version 2.5.12, or to 3.0.0-M6 for deployments tracking the 3.0.0 milestone line.
Enforce strict input size limits on any endpoint that forwards text to OpenNLP name finders.
Isolate OpenNLP processing in worker threads with per-request CPU and wall-clock timeouts.

Patch Information

The Apache OpenNLP project fixed the issue in versions 2.5.12 and 3.0.0-M6. See the Apache Security Mailing List Thread and the Openwall OSS-Security Discussion for advisory details.

Workarounds

Replace the built-in EMAIL and URL patterns with hardened, anchored regular expressions that avoid nested quantifiers.
Wrap RegexNameFinder.find calls in a bounded executor and cancel tasks exceeding a defined time budget.
Reject requests exceeding a small maximum payload size (for example, a few hundred bytes) before invoking name-finder logic.
Increase JVM thread stack size only as a temporary partial mitigation for the URL pattern; this does not address the EMAIL quadratic backtracking.

bash

# Upgrade via Maven dependency management
mvn versions:use-dep-version -Dincludes=org.apache.opennlp:opennlp-tools -DdepVersion=2.5.12 -DforceVersion=true