Apache OpenNLP CVE-2026-82617: a CVSS 10 that hangs

If anything in your stack runs user-supplied text through Apache OpenNLP's built-in name finders, you have a patch to schedule. CVE-2026-82617 carries a CVSS 10.0 and lands in RegexNameFinderFactory — the two convenience patterns almost everybody uses when they want email addresses and URLs pulled out of free text. A short crafted string drives them into runaway backtracking or stack exhaustion. The thread stalls or dies. The fix shipped in OpenNLP 2.5.12.

What actually happened

The Apache OpenNLP project fixed OPENNLP-1922 — "ReDoS / stack exhaustion in RegexNameFinderFactory EMAIL and URL patterns". Both built-in patterns exposed by opennlp.tools.namefind.RegexNameFinderFactory — DEFAULT_REGEX_NAME_FINDER.EMAIL and DEFAULT_REGEX_NAME_FINDER.URL — contain ambiguous nested quantifiers.

Two distinct failure modes, per the CVE record:

• EMAIL: a long local-part run with no @ pushes match time into quadratic growth. The CPU pins.
• URL: nested capturing repetition on an input with many query tokens overflows the stack. The processing thread throws and dies.

Affected: 2.0.0 through 2.5.11, and 3.0.0-M1 through 3.0.0-M5. Fixed in 2.5.12, or 3.0.0-M6 if you track the milestone line. Published September 11, 2026.

There is no authentication requirement, no special configuration, and no model file needed. The only precondition is that your application selected one of the two built-in finders — which is the default path in most tutorials.

Now the part the score gets wrong. The published CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — high confidentiality and integrity impact across the board. The described impact is denial of service. Nothing in the advisory says an attacker reads or writes your data. Treat the 10.0 as a routing signal, not a severity ruling.

Why this matters for your business

OpenNLP is quiet infrastructure. It sits inside Java services doing entity extraction on support tickets, contact-form submissions, resume uploads, product reviews, scraped listings, and inbound email. Nobody puts it on an architecture diagram. It ends up in a dependency tree via a document-processing library and stays there for four years.

The reachability question is the only one that matters here. A ReDoS on text you control is a bug report. A ReDoS on text a stranger types into your contact form is an outage. Answer this first: does untrusted text reach a RegexNameFinder built from DEFAULT_REGEX_NAME_FINDER.EMAIL or .URL? If yes, patch this week. If your only OpenNLP usage is batch processing of internal documents, it is a normal upgrade on your normal cadence.

Check transitively, not just your POM. Run mvn dependency:tree -Dincludes=org.apache.opennlp or ./gradlew dependencies and look for OpenNLP arriving through something else. That is how most teams have it.

Then put a guard in front of the finder regardless. Cap input length before it hits the pattern, run extraction on a bounded worker pool rather than your request threads, and set a timeout. A crafted string should cost one worker and one 500, not your whole pool. That control outlives this CVE — the next ambiguous regex in your stack will not get a CVE number at all.

Sources: Apache OpenNLP commit — OPENNLP-1922, CVE-2026-82617 record.