CVE-2026-43825 in OpenNLP
Summary
by MITRE • 07/06/2026
Untrusted Java Deserialization in Apache OpenNLP SvmDoccatModel
Versions Affected: before 3.0.0-M4 (libsvm document categorization module; introduced in OPENNLP-1808 and only present on the 3.x line)
Description: SvmDoccatModel.deserialize(InputStream) reads an attacker-controlled stream with java.io.ObjectInputStream and calls readObject() without an ObjectInputFilter installed. ObjectInputStream materialises every class referenced in the stream before the resulting object is cast to SvmDoccatModel, so the cast that follows readObject() executes only after the foreign object graph has already been deserialised in full.
If a Java deserialization gadget chain is available on the consumer's classpath, a crafted payload supplied to deserialize() executes arbitrary code in the JVM that loads it. Apache OpenNLP itself does not ship a known gadget chain, so the realistic risk is to downstream applications that embed the libsvm module alongside vulnerable transitive dependencies. The method is public and static, so any caller can pass an untrusted stream to it directly.
The practical impact is remote code execution against processes that load SvmDoccatModel instances from untrusted or semi-trusted origins.
Mitigation:
3.x users should upgrade to 3.0.0-M4.
Users who cannot upgrade immediately should treat all serialized SvmDoccatModel streams as untrusted input unless their provenance is verified, and should avoid invoking SvmDoccatModel.deserialize() on streams supplied by end users or fetched from third-party sources without integrity checks.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/06/2026
The vulnerability in Apache OpenNLP's SvmDoccatModel involves untrusted Java deserialization that presents a significant security risk to applications utilizing the libsvm document categorization module. This flaw exists in versions prior to 3.0.0-M4 and stems from the SvmDoccatModel.deserialize(InputStream) method which processes attacker-controlled data streams using java.io.ObjectInputStream without proper input filtering mechanisms. The vulnerability operates through a fundamental deserialization pattern where ObjectInputStream materializes every class referenced in the input stream before the resulting object is cast to SvmDoccatModel, meaning that arbitrary code execution occurs during the readObject() phase before any type checking or validation takes place. This design flaw aligns with CWE-502, which specifically addresses deserialization of untrusted data as a critical security weakness.
The operational impact of this vulnerability extends beyond the immediate Apache OpenNLP library to encompass downstream applications that integrate the libsvm module alongside potentially vulnerable transitive dependencies. While Apache OpenNLP itself does not include known gadget chains for exploitation, the presence of Java deserialization vulnerabilities in the broader classpath creates a realistic attack surface where malicious payloads can execute arbitrary code within the JVM context. The public and static nature of the deserialize method means that any caller can directly pass untrusted streams to it, eliminating barriers for potential attackers who might obtain serialized data from end users or third-party sources. This scenario represents a classic remote code execution vulnerability as outlined in ATT&CK technique T1203, where adversaries leverage deserialization flaws to execute malicious code remotely.
The attack vector relies on the presence of Java deserialization gadget chains within the application's classpath, which can be leveraged to construct payloads that trigger arbitrary code execution upon deserialization. The vulnerability essentially allows attackers to bypass normal security boundaries and execute commands with the privileges of the running JVM process. This risk is particularly concerning for web applications or services that deserialize user-provided data without proper validation or integrity checks. Organizations using affected versions must prioritize upgrading to 3.0.0-M4 or later releases, as this update addresses the core deserialization issue by implementing proper input filtering mechanisms. For those unable to upgrade immediately, defensive measures should include treating all serialized SvmDoccatModel streams as untrusted input and implementing robust integrity verification processes before invoking the deserialize method on any data originating from external sources. The vulnerability demonstrates how seemingly innocuous deserialization operations can become critical attack entry points when proper safeguards are not implemented.