deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-659w-93r5-9j6m
Package: org.apache.opennlp:opennlp-tools (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 2.5.9
Patched in: 2.5.9

Summary: Apache OpenNLP AbstractModelReader has an OOM Denial of Service via Unbounded Array Allocation

Details:
OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader 

Versions Affected: 

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.
GitHub Security Advisory: GHSA-cx4m-2p55-rw7j
Package: org.apache.opennlp:opennlp-tools (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: >= 3.0.0-M1, < 3.0.0-M3
Patched in: 3.0.0-M3

Summary: Apache OpenNLP ExtensionLoader Vulnerable to Arbitrary Class Instantiation via Model Manifest

Details:
Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader





Versions Affected: 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.
GitHub Security Advisory: GHSA-cx4m-2p55-rw7j
Package: org.apache.opennlp:opennlp-tools (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: < 2.5.9
Patched in: 2.5.9

Summary: Apache OpenNLP ExtensionLoader Vulnerable to Arbitrary Class Instantiation via Model Manifest

Details:
Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader





Versions Affected: 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.
GitHub Security Advisory: GHSA-4v8g-86x5-3vrc
Package: org.apache.opennlp:opennlp-tools (MAVEN)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: >= 3.0.0-M1, < 3.0.0-M3
Patched in: 3.0.0-M3

Summary: Apache OpenNLP DictionaryEntryPersistor Vulnerable to XML External Entity (XXE) via Unsanitized Dictionary Parsing

Details:
XML External Entity (XXE) via Unsanitized Dictionary Parsing in Apache OpenNLP DictionaryEntryPersistor


Versions Affected: before 2.5.9, before 3.0.0-M3


Description: The DictionaryEntryPersistor class initializes a static SAXParserFactory at class-load time without enabling FEATURE_SECURE_PROCESSING or disabling DTD processing. When create(InputStream, EntryInserter) is invoked, the only feature set on the XMLReader is namespace support — external entity resolution and DOCTYPE declarations remain fully enabled. An attacker who can supply a crafted dictionary file (e.g., a stop-word list or domain dictionary) 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, before the application processes a single dictionary entry. This is inconsistent with the project's own XmlUtil.createSaxParser() helper, which correctly sets FEATURE_SECURE_PROCESSING and disallow-doctype-decl and is used by all other XML parsing paths in the codebase. The public Dictionary(InputStream) constructor delegates directly to this method and is the documented API for loading user-supplied dictionaries, making untrusted input a realistic scenario.


Mitigation: 2.x users should upgrade to 2.5.9. 3.x users should upgrade to 3.0.0-M3. Users who cannot upgrade immediately should ensure that all dictionary files are sourced from trusted origins and should consider wrapping the Dictionary(InputStream) constructor with input validation that rejects any XML containing a DOCTYPE declaration before it reaches the parser.
GitHub Security Advisory: GHSA-4v8g-86x5-3vrc
Package: org.apache.opennlp:opennlp-tools (MAVEN)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: < 2.5.9
Patched in: 2.5.9

Summary: Apache OpenNLP DictionaryEntryPersistor Vulnerable to XML External Entity (XXE) via Unsanitized Dictionary Parsing

Details:
XML External Entity (XXE) via Unsanitized Dictionary Parsing in Apache OpenNLP DictionaryEntryPersistor


Versions Affected: before 2.5.9, before 3.0.0-M3


Description: The DictionaryEntryPersistor class initializes a static SAXParserFactory at class-load time without enabling FEATURE_SECURE_PROCESSING or disabling DTD processing. When create(InputStream, EntryInserter) is invoked, the only feature set on the XMLReader is namespace support — external entity resolution and DOCTYPE declarations remain fully enabled. An attacker who can supply a crafted dictionary file (e.g., a stop-word list or domain dictionary) 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, before the application processes a single dictionary entry. This is inconsistent with the project's own XmlUtil.createSaxParser() helper, which correctly sets FEATURE_SECURE_PROCESSING and disallow-doctype-decl and is used by all other XML parsing paths in the codebase. The public Dictionary(InputStream) constructor delegates directly to this method and is the documented API for loading user-supplied dictionaries, making untrusted input a realistic scenario.


Mitigation: 2.x users should upgrade to 2.5.9. 3.x users should upgrade to 3.0.0-M3. Users who cannot upgrade immediately should ensure that all dictionary files are sourced from trusted origins and should consider wrapping the Dictionary(InputStream) constructor with input validation that rejects any XML containing a DOCTYPE declaration before it reaches the parser.
GitHub Security Advisory: GHSA-35xx-9xrg-gwhf
Package: org.apache.atlas:apache-atlas (MAVEN)
Severity: HIGH (CVSS 7.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 0.8, < 2.5.0
Patched in: 2.5.0

Summary: Apache Atlas has a Code Injection Vulnerability

Details:
### Description:
Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Atlas.

Apache Atlas exposes a DSL search endpoint that accepts user-supplied query strings. Attacker can alter Gremlin traversal logic within grammar-allowed characters to access unintended data.


### Affected Version:
This issue affects Apache Atlas: from 0.8-incubating through 2.4.0.


For affected versions >= 2.0.0, the vulnerability is only exploitable when Atlas is deployed with below non-default configuration.


`atlas.dsl.executor.traversal=false`


### Mitigation:
Users are recommended to upgrade to version 2.5.0, which fixes the issue.
GitHub Security Advisory: GHSA-j9rh-p96m-mhhp
Package: org.jopendocument:jOpenDocument (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: <= 1.3
Patched in: unpatched

Summary: jOpenDocument has an improper restriction of XML external entity reference vulnerability

Details:
Improper restriction of XML external entity reference vulnerability in ILM Informatique jOpenDocument allows Data Serialization External Entities Blowup.

This issue affects jOpenDocument: 1.5.
GitHub Security Advisory: GHSA-8297-v2rf-2p32
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.2.0, < 2.2.6
Patched in: 2.2.6

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data

Details:
Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.

The fix checks if the class is present in the accepted class filter before calling Class.forName(). 

Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5.

The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.
GitHub Security Advisory: GHSA-8297-v2rf-2p32
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.1.0, < 2.1.11
Patched in: 2.1.11

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data

Details:
Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.

The fix checks if the class is present in the accepted class filter before calling Class.forName(). 

Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5.

The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.
GitHub Security Advisory: GHSA-8297-v2rf-2p32
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.0.0, < 2.0.28
Patched in: 2.0.28

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data

Details:
Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.

The fix checks if the class is present in the accepted class filter before calling Class.forName(). 

Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5.

The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.
GitHub Security Advisory: GHSA-gjx6-h8hm-c9rq
Package: com.xuxueli:xxl-job-admin (MAVEN)
Severity: LOW (CVSS 5.4)
CWE: CWE-99: Improper Control of Resource Identifiers ('Resource Injection'), CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 3.1.1
Patched in: 3.2.0

Summary: xxl-job Jobs Handler remove function allows improper control of resource identifiers via ID parameter

Details:
A vulnerability was found in Xuxueli xxl-job up to 3.1.1. Affected by this issue is the function remove of the file /src/main/java/com/xxl/job/admin/controller/JobInfoController.java of the component Jobs Handler. Performing manipulation of the argument ID results in improper control of resource identifiers. Remote exploitation of the attack is possible. The exploit has been made public and could be used.
GitHub Security Advisory: GHSA-6rq7-m52p-8pqg
Package: com.xuxueli:xxl-job-admin (MAVEN)
Severity: LOW (CVSS 4.3)
CWE: CWE-99: Improper Control of Resource Identifiers ('Resource Injection'), CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 3.1.1
Patched in: 3.2.0

Summary: xxl-job Vulnerable to Resource Injection and Authorization Bypass Through User-Controlled Key

Details:
A vulnerability has been found in Xuxueli xxl-job up to 3.1.1. Affected by this vulnerability is the function getJobsByGroup of the file /src/main/java/com/xxl/job/admin/controller/JobLogController.java. Such manipulation of the argument jobGroup leads to improper control of resource identifiers. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.
GitHub Security Advisory: GHSA-565h-44m8-4c2v
Package: com.xuxueli:xxl-job-admin (MAVEN)
Severity: LOW (CVSS 3.7)
CWE: CWE-326: Inadequate Encryption Strength
Vulnerable versions: <= 3.1.1
Patched in: 3.2.0

Summary: xxl-job has Inadequate Encryption Strength 

Details:
A vulnerability was found in Xuxueli xxl-job up to 3.1.1 and classified as problematic. Affected by this issue is the function makeToken of the file src/main/java/com/xxl/job/admin/controller/IndexController.java of the component Token Generation. The manipulation leads to password hash with insufficient computational effort. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used.
GitHub Security Advisory: GHSA-jfg9-48mv-9qgx
Package: io.netty:netty-codec-mqtt (MAVEN)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 4.1.132.Final
Patched in: 4.1.133.Final

Summary: Netty MQTT: Resource exhaustion in MqttDecoder

Details:
### Impact
The MQTT 5 header Properties section is parsed and buffered _before_ any message size limit is applied.

Specifically, in `MqttDecoder`, the `decodeVariableHeader()` method is called before the `bytesRemainingBeforeVariableHeader > maxBytesInMessage` check. The `decodeVariableHeader()` can call other methods which will call `decodeProperties()`. Effectively, Netty does not apply any limits to the size of the properties being decoded.

Additionally, because `MqttDecoder` extends `ReplayingDecoder`, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion.

This can cause high resource usage in both CPU and memory.

### Resources
`ANT-2026-09608`
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901027
GitHub Security Advisory: GHSA-jfg9-48mv-9qgx
Package: io.netty:netty-codec-mqtt (MAVEN)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 4.2.0.Alpha1, <= 4.2.12.Final
Patched in: 4.2.13.Final

Summary: Netty MQTT: Resource exhaustion in MqttDecoder

Details:
### Impact
The MQTT 5 header Properties section is parsed and buffered _before_ any message size limit is applied.

Specifically, in `MqttDecoder`, the `decodeVariableHeader()` method is called before the `bytesRemainingBeforeVariableHeader > maxBytesInMessage` check. The `decodeVariableHeader()` can call other methods which will call `decodeProperties()`. Effectively, Netty does not apply any limits to the size of the properties being decoded.

Additionally, because `MqttDecoder` extends `ReplayingDecoder`, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion.

This can cause high resource usage in both CPU and memory.

### Resources
`ANT-2026-09608`
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901027
GitHub Security Advisory: GHSA-vf5j-865m-mq7c
Package: org.apache.mina:mina-core (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.2.0, < 2.2.7
Patched in: 2.2.7

Summary: Apache MINA vulnerable to Deserialization of Untrusted Data (CVE-2026-41635 Incomplete Fix)

Details:
The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:

Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.

The fix checks if the class is present in the accepted class filter before calling Class.forName(). 

Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6.

The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier.

Affected are applications using Apache MINA that call  IoBuffer.getObject().

Applications using Apache MINA are advised to upgrade.