CVE-2026-82617 is a critical (9.8) regular expression denial of service in Apache OpenNLP. The built-in EMAIL and URL name finders can be driven into heavy backtracking or stack exhaustion by crafted text. Upgrade opennlp-tools to 2.5.12, or opennlp-core to 3.0.0-M6 on the milestone line.
What's affected
The Apache OpenNLP announcement lists these affected versions:
- org.apache.opennlp:opennlp-tools from 2.0.0 through 2.5.11. Fixed in 2.5.12.
- org.apache.opennlp:opennlp-core from 3.0.0-M1 through 3.0.0-M5. Fixed in 3.0.0-M6.
You are exposed only if your application gets the default finders through RegexNameFinderFactory.getDefaultRegexNameFinders and then runs them on untrusted text with RegexNameFinder.find. Code that does not use those two built-in patterns is not affected by this description.
How to check if you're exposed
Find the library in your builds.
mvn dependency:tree | grep -i opennlp
./gradlew dependencies | grep -i opennlp
Then search your own code for the entry points named in the announcement.
grep -rn "getDefaultRegexNameFinders\|RegexNameFinderFactory" src/
A match plus input that comes from users, documents or the network means you are exposed. The free in-browser scan at https://gold.safeguard.sh/scan can list the library in a manifest for you.
What to do now
- Find every project that depends on opennlp-tools or opennlp-core, including transitive uses.
- Upgrade opennlp-tools to 2.5.12 or later, or opennlp-core to 3.0.0-M6 if you track the milestone line.
- Search your code for RegexNameFinderFactory and the default finders, and note which handle untrusted text.
- Until you upgrade, cap the length of text you pass to these finders and run them with a timeout.
- Rebuild and redeploy, then confirm the resolved version in your dependency tree.
Why it matters
The weakness is CWE-1333, inefficient regular expression complexity. Per the announcement, both patterns contain ambiguous nested quantifiers. For the EMAIL pattern, a long run of local-part characters with no at sign makes the matcher rescan from every starting point, so cost grows with the square of the input. About 32 KB takes several seconds of CPU in one call.
The URL pattern nests a repetition inside another, and the JDK matcher recurses once per query token. Roughly 4 KB of many ampersand separated tokens can overflow the thread stack and kill the calling thread, and about 1 KB can do it on a thread with a small stack. The result is denial of service. The 9.8 score reflects the vector's network reach and the scoring of availability impact, so judge your real risk by whether untrusted text reaches the finders. The record is not listed in CISA's KEV catalog.
Denial of service through regular expressions is easy to underestimate because the input is small. The announcement gives numbers. About 32 KB of text, with no at sign, makes the EMAIL pattern burn several seconds of CPU in a single call, and each doubling of the input multiplies the cost about four times. About 4 KB of query tokens can kill a thread through the URL pattern, and about 1 KB can do so on a thread with a small stack.
That is the shape of the risk in a real service. One request pins a worker or kills one, and a modest stream of requests takes the service down. Search indexing, document ingestion and chat pipelines that run entity extraction on user text are the typical exposures.
If you cannot upgrade immediately, three controls help. Cap the size of text passed to these finders. Run extraction on a bounded worker pool with timeouts, so one request cannot pin everything. And catch StackOverflowError at the worker boundary so a thread death is logged and replaced. None of that replaces the upgrade, but it limits the blast radius while you roll it out.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect my application if I never call the regex finders?
The announcement ties the issue to the two built-in EMAIL and URL patterns. If you do not use them, the described path is not reachable, though you should upgrade anyway when convenient.
Sources
Last reviewed: 19 October 2026.
