Apache OpenNLP up to 2.5.8/3.0.0-M2 AbstractModelReader denial of service

Summaryinfo

A vulnerability was found in Apache OpenNLP up to 2.5.8/3.0.0-M2. It has been rated as problematic. This impacts an unknown function of the component AbstractModelReader. This manipulation causes denial of service. This vulnerability is tracked as CVE-2026-42440. The attack is possible to be carried out remotely. No exploit exists. Upgrading the affected component is advised.

Detailsinfo

A vulnerability has been found in Apache OpenNLP up to 2.5.8/3.0.0-M2 and classified as problematic. Affected by this vulnerability is an unknown function of the component AbstractModelReader. The manipulation with an unknown input leads to a denial of service vulnerability. The CWE definition for the vulnerability is CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use. As an impact it is known to affect availability. The summary by CVE is:

OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader  Versions Affected:  before 1.9.5 before 2.5.9 before 3.0.0-M3  Description: The AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUM_PREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source. A crafted .bin model file in which any of these count fields is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load. The practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins.   Mitigation: * 2.x users should upgrade to 2.5.9. * 3.x users should upgrade to 3.0.0-M3. Note: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Users who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.

It is possible to read the advisory at lists.apache.org. This vulnerability is known as CVE-2026-42440. The exploitation appears to be easy. The attack can be launched remotely. The technical details are unknown and an exploit is not publicly available. The attack technique deployed by this issue is T1499 according to MITRE ATT&CK.

Upgrading to version 2.5.9 or 3.0.0-M3 eliminates this vulnerability.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-27031). Statistical analysis made it clear that VulDB provides the best quality for 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
• 3.0.0-M2

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

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion