Apache OpenNLP exposes arbitrary class instantiation vulnerability

Per the oss-sec mailing list post by Richard Zowalla, CVE-2026-42027 is a vulnerability in Apache OpenNLP's model loading path. The advisory labels the issue as "moderate" and lists affected releases as Apache OpenNLP (org.apache.opennlp:opennlp-tools) before 2.5.9 and 3.0 before 3.0.0-M3. The report explains that ExtensionLoader.instantiateExtension(Class, String) loads a class named in a model archive's manifest.properties via Class.forName() and then invokes its no-arg constructor; the check that verifies the loaded class is a subtype runs only after Class.forName() has already initialized the class. The advisory notes exploitation requires a class with attacker-useful side effects in its static initializer to already exist on the classpath and that a secondary vector can force constructors of shipped subclasses to run during model load.

The report documents that Class.forName() performs static initialization before returning, so a manifest-controlled class name can trigger arbitrary static initializers even if the class later fails the type check. The patch for the issue introduces a package-prefix allowlist that is consulted before calling Class.forName(), preventing initialization of disallowed classes; classes under the opennlp. prefix remain permitted by default, per the advisory.

Libraries and frameworks that dynamically load classes by name are frequently exposed to this class of risk when they perform type or safety checks only after loading. Industry-pattern observations: projects that accept third-party artifacts or models increase their attack surface if they permit manifest-controlled class names, especially in ecosystems where community model sharing (for example, model hubs) is common. A package-prefix allowlist is a pragmatic mitigation that reduces the blast radius by bounding which packages may be instantiated at load time.

For maintainers and deployers of applications using OpenNLP, the practical risk depends on what classes are present on the runtime classpath. Container images or application distributions that include libraries with side-effecting static initializers widen the exploit surface. The oss-sec advisory explicitly recommends upgrading to 2.5.9 or 3.0.0-M3 as the remediation.

Observables to track include model provenance policies, audits of included libraries for static initializers or unsafe static blocks, and whether runtime environments allow untrusted model loading. Observers will also watch whether other libraries adopt pre-load allowlists or stricter manifest validation as a standard pattern.