Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader Versions Affected: before 1.9.5, before 2.5.9, before 3.0.0-M3 Description: The ExtensionLoader.instantiateExtension(Class, String) method loads a class by its fully-qualified name via Class.forName() and invokes its no-arg constructor, with the class name sourced from the manifest.properties entry of a model archive. The existing isAssignableFrom check correctly rejects classes that are not subtypes of the expected extension interface (BaseToolFactory for factory=, ArtifactSerializer for serializer-class-*), but the check runs after Class.forName() has already loaded and initialized the named class. Class.forName() with default initialization semantics executes the target class's static initializer before returning, so an attacker who can supply a crafted model archive can cause the static initializer of any class on the classpath to run during model loading, regardless of whether that class passes the subsequent type check. Exploitation requires a class with attacker-useful side effects in its static initializer (for example, JNDI lookup, outbound network I/O, or filesystem access) to be present on the classpath, so this is not a drop-in remote code execution; however, the attack surface grows as third-party model distribution becomes more common (community model repositories, Hugging Face-style sharing), where users routinely load model files from origins they do not control. A secondary, narrower vector affects deployments that ship legitimate BaseToolFactory or ArtifactSerializer subclasses with side-effecting no-arg constructors: a malicious manifest can name such a class and force its constructor to run during model load. Mitigation: * 2.x users should upgrade to 2.5.9. * 3.x users should upgrade to 3.0.0-M3. Note: The fix introduces a package-prefix allowlist that is consulted before Class.forName() is invoked, so the static initializer of a disallowed class is never executed. Classes under the opennlp. prefix remain permitted by default. Deployments that load models referencing factories or serializers 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 that all model files are sourced from trusted origins and should audit their classpath for classes with side-effecting static initializers or constructors, particularly any that perform JNDI lookups, network requests, or filesystem operations during class initialization.

The version of IBM Cognos Analytics installed on the remote host is 12.1.x prior to 12.1.3 FP2. It is, therefore, affected by multiple vulnerabilities as referenced in the IBM Security Bulletin No. 7287209. These vulnerabilities are applicable only to version 12.1.3 due to newer functionalities and an updated software stack:

  - Arbitrary class instantiation via model manifest in Apache OpenNLP ExtensionLoader. The     ExtensionLoader.instantiateExtension() method loads a class by its fully-qualified name via     Class.forName() and invokes its no-arg constructor, with the class name sourced from the     manifest.properties entry of a model archive. An attacker who can supply a crafted model archive can     cause the static initializer of any class on the classpath to run during model loading.
    (CVE-2026-42027)

  - XML External Entity (XXE) via unsanitized dictionary parsing in Apache OpenNLP     DictionaryEntryPersistor. An attacker who can supply a crafted dictionary file containing a malicious     DOCTYPE declaration can trigger local file disclosure via file:// entity references or server-side     request forgery via http:// entity references during SAX parsing. (CVE-2026-40682)

  - An authenticated attacker may bypass the fix in CVE-2026-34197 by adding a connector using an HTTP     Discovery transport via BrokerView.addNetworkConnector or BrokerView.addConnector through Jolokia if the     activemq-http module is on the classpath, resulting in arbitrary code execution on the Apache ActiveMQ     broker's JVM. (CVE-2026-40466)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader Versions Affected:
    before 1.9.5, before 2.5.9, before 3.0.0-M3 Description: The ExtensionLoader.instantiateExtension(Class,
    String) method loads a class by its fully-qualified name via Class.forName() and invokes its no-arg
    constructor, with the class name sourced from the manifest.properties entry of a model archive. The
    existing isAssignableFrom check correctly rejects classes that are not subtypes of the expected extension
    interface (BaseToolFactory for factory=, ArtifactSerializer for serializer-class-*), but the check runs
    after Class.forName() has already loaded and initialized the named class. Class.forName() with default
    initialization semantics executes the target class's static initializer before returning, so an attacker
    who can supply a crafted model archive can cause the static initializer of any class on the classpath to
    run during model loading, regardless of whether that class passes the subsequent type check. Exploitation
    requires a class with attacker-useful side effects in its static initializer (for example, JNDI lookup,
    outbound network I/O, or filesystem access) to be present on the classpath, so this is not a drop-in
    remote code execution; however, the attack surface grows as third-party model distribution becomes more
    common (community model repositories, Hugging Face-style sharing), where users routinely load model files
    from origins they do not control. A secondary, narrower vector affects deployments that ship legitimate
    BaseToolFactory or ArtifactSerializer subclasses with side-effecting no-arg constructors: a malicious
    manifest can name such a class and force its constructor to run during model load. Mitigation: * 2.x users
    should upgrade to 2.5.9. * 3.x users should upgrade to 3.0.0-M3. Note: The fix introduces a package-prefix
    allowlist that is consulted before Class.forName() is invoked, so the static initializer of a disallowed
    class is never executed. Classes under the opennlp. prefix remain permitted by default. Deployments that
    load models referencing factories or serializers 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 that all model files are sourced from trusted
    origins and should audit their classpath for classes with side-effecting static initializers or
    constructors, particularly any that perform JNDI lookups, network requests, or filesystem operations
    during class initialization. (CVE-2026-42027)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader Versions Affected:
    before 1.9.5, before 2.5.9, before 3.0.0-M3 Description: The ExtensionLoader.instantiateExtension(Class,     String) method loads a class by its fully-qualified name via Class.forName() and invokes its no-arg     constructor, with the class name sourced from the manifest.properties entry of a model archive. The     existing isAssignableFrom check correctly rejects classes that are not subtypes of the expected extension     interface (BaseToolFactory for factory=, ArtifactSerializer for serializer-class-*), but the check runs     after Class.forName() has already loaded and initialized the named class. Class.forName() with default     initialization semantics executes the target class's static initializer before returning, so an attacker     who can supply a crafted model archive can cause the static initializer of any class on the classpath to     run during model loading, regardless of whether that class passes the subsequent type check. Exploitation     requires a class with attacker-useful side effects in its static initializer (for example, JNDI lookup,     outbound network I/O, or filesystem access) to be present on the classpath, so this is not a drop-in     remote code execution; however, the attack surface grows as third-party model distribution becomes more     common (community model repositories, Hugging Face-style sharing), where users routinely load model files     from origins they do not control. A secondary, narrower vector affects deployments that ship legitimate     BaseToolFactory or ArtifactSerializer subclasses with side-effecting no-arg constructors: a malicious     manifest can name such a class and force its constructor to run during model load. Mitigation: * 2.x users     should upgrade to 2.5.9. * 3.x users should upgrade to 3.0.0-M3. Note: The fix introduces a package-prefix     allowlist that is consulted before Class.forName() is invoked, so the static initializer of a disallowed     class is never executed. Classes under the opennlp. prefix remain permitted by default. Deployments that     load models referencing factories or serializers 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 that all model files are sourced from trusted     origins and should audit their classpath for classes with side-effecting static initializers or     constructors, particularly any that perform JNDI lookups, network requests, or filesystem operations     during class initialization. (CVE-2026-42027)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
347959	IBM Cognos Analytics 12.1.x < 12.1.3 FP2 Multiple Vulnerabilities (7287209)	Nessus	CGI abuses	Remote	high
441560	SCA: security update for org.apache.opennlp:opennlp-tools (GHSA-cx4m-2p55-rw7j)	Tenable Cloud Security	SCA Checks	Local	high
441560	SCA: security update for org.apache.opennlp:opennlp-tools (GHSA-cx4m-2p55-rw7j)	Tenable Self-Hosted Container Security	SCA Checks	Local	high
312234	Linux Distros Unpatched Vulnerability : CVE-2026-42027	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-42027

high

Tenable Plugins

high

high

high

high