CVE-2026-63317 in OpenNLP
Summary
by MITRE • 07/24/2026
Arbitrary Class Instantiation via XML Feature Generator Descriptor and Format Name in Apache OpenNLP
Versions Affected:
- before 2.5.10 - before 3.0.0-M5
Description:
Three code paths in Apache OpenNLP load a class by its fully-qualified name via Class.forName() and invoke its no-arg constructor without any prior validation of the class name or its type.
The affected paths are:
(1) GeneratorFactory, which reads the class attribute of generator elements in an XML feature generator descriptor; such descriptors are embedded as artifacts in model archives (e.g. TokenNameFinder and POSTagger models) and are parsed during model loading, so an attacker who can supply a crafted model archive controls the class name directly.
(2) StreamFactoryRegistry.getFactory(Class, String), which falls back to interpreting an unregistered format name as the fully-qualified class name of an ObjectStreamFactory; this is exploitable in applications that pass untrusted format names (e.g. exposing the -format parameter of the command-line tooling to external input).
(3) StringInterners, which instantiates the interner implementation named by the opennlp.interner.class system property; this value is normally deployer-controlled, so it is hardened as defense in depth rather than being independently attacker-reachable.
Exploitation requires a class with attacker-useful side effects in its static initializer or no-arg constructor (JNDI lookup, outbound network I/O, filesystem access) to be present on the classpath, so this is not drop-in remote code execution. T
Mitigation:
Upgrade to a fixed release.
The fix routes all three paths through ExtensionLoader.instantiateExtension(...), which consults a package-prefix allowlist before Class.forName() is invoked, so a disallowed class is never loaded, initialized, or constructed. Classes under the opennlp. prefix remain permitted by default. Deployments that load models referencing feature generator factories, object stream factories, or string interners outside opennlp.* must opt those packages in, either programmatically via ExtensionLoader.registerAllowedPackage(String) before the first model load, or by setting the OPENNLP_EXT_ALLOWED_PACKAGES system property to a comma-separated list of allowed package prefixes.
Users who cannot upgrade immediately should ensure all model files and format names are sourced from trusted origins and should audit their classpath for classes with side-effecting static initializers or constructors.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/24/2026
Apache OpenNLP contains a vulnerability that allows arbitrary class instantiation through XML feature generator descriptors and format names, enabling potential remote code execution via unvalidated class loading mechanisms. This issue affects versions prior to 2.5.10 and before 3.0.0-M5 and stems from three distinct code paths where Class.forName() is invoked without proper validation of the class name or type. The vulnerability manifests in GeneratorFactory when parsing XML descriptors embedded within model archives, such as those used by TokenNameFinder and POSTagger models, allowing attackers to supply malicious class names directly through crafted model files. Additionally, StreamFactoryRegistry.getFactory(Class, String) exhibits similar behavior when interpreting unregistered format names as fully-qualified class names for ObjectStreamFactory implementations, making command-line tools vulnerable when external input controls the -format parameter. A third vector involves StringInterners that instantiate classes based on the opennlp.interner.class system property, which can be manipulated by attackers in certain deployment scenarios.
The technical flaw aligns with CWE-470, which describes the use of insecure deserialization or dynamic class loading without proper validation mechanisms. The vulnerability is particularly concerning because it operates at the Java class loading level, where malicious classes can execute arbitrary code during static initialization or constructor execution. Attackers must have access to a class on the classpath that performs side effects such as JNDI lookups, network I/O, or filesystem operations to achieve meaningful exploitation. This limitation prevents immediate remote code execution but allows for sophisticated attacks including command and control communication, data exfiltration, or privilege escalation. The ATT&CK framework categorizes this vulnerability under T1059.007 (Command and Scripting Interpreter: Python) and potentially T1105 (Remote File Execution) when combined with other attack vectors.
The operational impact of this vulnerability extends beyond simple code execution to encompass complete system compromise in environments where attackers can influence model loading or format name inputs. Organizations using Apache OpenNLP for natural language processing tasks face potential exposure when processing untrusted data, particularly in web applications or services that accept user-provided models or parameters. The vulnerability is especially dangerous in cloud environments or multi-tenant systems where one user's malicious input could affect other users or system components. The three attack vectors create multiple potential entry points for exploitation, with the XML descriptor path being most concerning due to its ability to be embedded within model archives and automatically executed during normal application operation.
The mitigation strategy implemented in fixed releases addresses the root cause by introducing an ExtensionLoader.instantiateExtension() mechanism that enforces package-prefix allowlists before any Class.forName() invocation occurs. This defense-in-depth approach ensures that only explicitly permitted packages can have their classes loaded, with opennlp.* packages remaining allowed by default to maintain backward compatibility. Deployment administrators must explicitly register additional packages via ExtensionLoader.registerAllowedPackage(String) or through the OPENNLP_EXT_ALLOWED_PACKAGES system property when using external libraries or custom implementations. Organizations unable to upgrade immediately should implement strict input validation, source verification for all model files and format names, and comprehensive classpath auditing to identify potentially malicious classes with side-effecting static initializers or constructors. The fix represents a significant improvement over previous approaches that relied solely on runtime checks, providing proactive protection against future vulnerabilities in similar loading mechanisms.
This vulnerability highlights the critical importance of secure class loading practices in Java applications and demonstrates how seemingly innocuous features can become security risks when proper validation is omitted. The attack surface expands beyond direct exploitation to include potential privilege escalation scenarios where attackers might use the loaded classes to gain unauthorized access to system resources or perform operations beyond their intended scope. Organizations should review all dynamic loading mechanisms within their applications, particularly those involving external configuration or user input, to prevent similar vulnerabilities from being introduced in other components of their software stack. The remediation approach taken by Apache OpenNLP serves as a model for how security teams can address such issues through proactive code changes rather than reactive patches, emphasizing the importance of validation and access control in preventing unauthorized code execution scenarios.