ghsa-h84g-69h7-mw6v
CVSS 7.1 osv_maven### Impact Prior to version 0.6.0, mchange-commons-java includes a JNDI `ObjectFactory` implementation (`com.mchange.v2.naming.JavaBeanObjectFactory`) willing to construct objects of arbitrary classes and initialize "JavaBean"-style properties. There are classes for which this kind of initialization is unsafe. For example, setting the "contentType" property of a Swing `JEditorPane` to `text/html` and the "text" property to HTML containing a stylesheet <link> will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. This issue is aggravated by mchange-commons-java's `ReferenceIndirector`, by which malicious JNDI `Reference` objects could be smuggled in for dereferencing by applications anywhere a Java-serialized object might be read. Prior to version 0.5.0, the same mchange-commons-java `ObjectFactory` would interpret `BinaryRefAddress` elements as Java-serialized objects, and deserialize unexpected objects that potentially execute malicious behavior on initialization. Although this author is unaware of any code within mchange-commons-java itself that can be abused to execute code on deserialization, this mechanism can be used to trigger well-known "deserialization gadget chains" involving other libraries. For example, in JVMs prior to Java 16 with Apache libraries [`commons-beanutils`](https://commons.apache.org/proper/commons-beanutils/) and [`commons-collections`](https://commons.apache.org/proper/commons-collections/) on the application `CLASSPATH`, [objects can be crafted](https://gist.github.com/frohoff/9eb8811761ff989b3ac0) that will execute arbitrary commands on deserialization. (Thanks to Valerio Mulas for a proof-of-concept.) ### Patches mchange-commons-java v0.5.0 eliminates all support for deserializing Java objects in `com.mchange.v2.naming.JavaBeanObjectFactory`, unless an application explicitly extends that class to restore it. This prevents mchange-commons-java from enabling JNDI injection to trigger common "deserialization gadgets". mchange-commons-java v0.6.0 imposes a whitelist upon what classes `com.mchange.v2.naming.JavaBeanObjectFactory` consents to materialize, preventing the use of maliciously constructed `Reference` instances to initialize arbitrary, potentially malicious, objects. mchange-commons-java v0.6.0 disables the `ReferenceIndirector` mechanism by default. This mechanism has been abused by attackers to inject dangerous JNDI `Reference` objects by causing an application to deserialize a malicious Java-serialized object. (The functionality remains for applications that need it, gated behind a restrictive configuration parameter. This is "defense-in-depth"; the hardening of `JavaBeanObjectFactory` on its own should be sufficient to prevent known `Reference`-based attacks. But perhaps there are other insecure `ObjectFactory` implementations on the `CLASSPATH` or vulnerabilities as-yet-unknown.) ### Workarounds Upgrading to the current version of mchange-commons-java is strongly recommended. Most applications that install mchange-commons-java do so to support the c3p0 JDBC Connection pooling library. When upgrading mchange-commons-java, be sure to update c3p0 as well, or better yet, upgrade to c3p0 >=v0.14.0 and bring in a patched mchange-commons-java transitively. Maintaining rigorous serialization filters can prevent many attacks (but not attacks requiring only construction of a named class and initialization of simple JavaBeans properties, as described for `JEditorPane` above). The vulnerabilities that this advisory addresses all begin with arranging for an application to lookup a malicious JNDI `Reference` or deserialize a malicious Java-serialized object. Assiduously preventing an application from ever encountering such a `Reference` or serialized object is hypothetically a workaround. But relying upon perfection is usually bad planning. The most common known attacks rely upon JVM-internal XSLT code that has been made inaccessible on Java 16 and beyond. Running on a more recent JVM is a mitigating workaround. ### Resources The vulnerabilities and security upgrades are documented in c3p0's manual. Please see c3p0's [Security Note](https://www.mchange.com/projects/c3p0/#security-note) and [Configuring Security](https://www.mchange.com/projects/c3p0/#configuring_security). ### Credits mchange-commons-java thanks 4ra1n and unam4 on Github for a proof-of-concept.
- Published
- unknown
- Last Modified
- unknown
CVSS details not available.
No product information available.
No linked vulnerabilities found.
{
"affected": [
{
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/08/GHSA-h84g-69h7-mw6v/GHSA-h84g-69h7-mw6v.json"
},
"package": {
"ecosystem": "Maven",
"name": "com.mchange:mchange-commons-java",
"purl": "pkg:maven/com.mchange/mchange-commons-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.2.1-RELEASE",
"0.2.10",
"0.2.11",
"0.2.12",
"0.2.13",
"0.2.14",
"0.2.15",
"0.2.16",
"0.2.17",
"0.2.18",
"0.2.19",
"0.2.2",
"0.2.20",
"0.2.3",
"0.2.3.1",
"0.2.3.2",
"0.2.3.3",
"0.2.3.4",
"0.2.4",
"0.2.5",
"0.2.6",
"0.2.6.1",
"0.2.6.2",
"0.2.6.3",
"0.2.6.5",
"0.2.7",
"0.2.8",
"0.2.9",
"0.3.0",
"0.3.1",
"0.3.2",
"0.4.0",
"0.5.0"
]
}
],
"aliases": [
"CVE-2026-55153"
],
"database_specific": {
"cwe_ids": [
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-14T19:29:20Z",
"nvd_published_at": "2026-07-01T21:17:03Z",
"severity": "HIGH"
},
"details": "### Impact\nPrior to version 0.6.0, mchange-commons-java includes a JNDI `ObjectFactory` implementation (`com.mchange.v2.naming.JavaBeanObjectFactory`) willing to construct objects of arbitrary classes and initialize \"JavaBean\"-style properties. There are classes for which this kind of initialization is unsafe. For example, setting the \"contentType\" property of a Swing `JEditorPane` to `text/html` and the \"text\" property to HTML containing a stylesheet <link> will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. This issue is aggravated by mchange-commons-java's `ReferenceIndirector`, by which malicious JNDI `Reference` objects could be smuggled in for dereferencing by applications anywhere a Java-serialized object might be read. \n\nPrior to version 0.5.0, the same mchange-commons-java `ObjectFactory` would interpret `BinaryRefAddress` elements as Java-serialized objects, and deserialize unexpected objects that potentially execute malicious behavior on initialization. Although this author is unaware of any code within mchange-commons-java itself that can be abused to execute code on deserialization, this mechanism can be used to trigger well-known \"deserialization gadget chains\" involving other libraries. For example, in JVMs prior to Java 16 with Apache libraries [`commons-beanutils`](https://commons.apache.org/proper/commons-beanutils/) and [`commons-collections`](https://commons.apache.org/proper/commons-collections/) on the application `CLASSPATH`, [objects can be crafted](https://gist.github.com/frohoff/9eb8811761ff989b3ac0) that will execute arbitrary commands on deserialization. (Thanks to Valerio Mulas for a proof-of-concept.)\n\n### Patches\nmchange-commons-java v0.5.0 eliminates all support for deserializing Java objects in `com.mchange.v2.naming.JavaBeanObjectFactory`, unless an application explicitly extends that class to restore it. This prevents mchange-commons-java from enabling JNDI injection to trigger common \"deserialization gadgets\".\n\nmchange-commons-java v0.6.0 imposes a whitelist upon what classes `com.mchange.v2.naming.JavaBeanObjectFactory` consents to materialize, preventing the use of maliciously constructed `Reference` instances to initialize arbitrary, potentially malicious, objects.\n\nmchange-commons-java v0.6.0 disables the `ReferenceIndirector` mechanism by default. This mechanism has been abused by attackers to inject dangerous JNDI `Reference` objects by causing an application to deserialize a malicious Java-serialized object. (The functionality remains for applications that need it, gated behind a restrictive configuration parameter. This is \"defense-in-depth\"; the hardening of `JavaBeanObjectFactory` on its own should be sufficient to prevent known `Reference`-based attacks. But perhaps there are other insecure `ObjectFactory` implementations on the `CLASSPATH` or vulnerabilities as-yet-unknown.)\n\n### Workarounds\nUpgrading to the current version of mchange-commons-java is strongly recommended. Most applications that install mchange-commons-java do so to support the c3p0 JDBC Connection pooling library. When upgrading mchange-commons-java, be sure to update c3p0 as well, or better yet, upgrade to c3p0 >=v0.14.0 and bring in a patched mchange-commons-java transitively.\n\nMaintaining rigorous serialization filters can prevent many attacks (but not attacks requiring only construction of a named class and initialization of simple JavaBeans properties, as described for `JEditorPane` above).\n\nThe vulnerabilities that this advisory addresses all begin with arranging for an application to lookup a malicious JNDI `Reference` or deserialize a malicious Java-serialized object. Assiduously preventing an application from ever encountering such a `Reference` or serialized object is hypothetically a workaround. But relying upon perfection is usually bad planning.\n\nThe most common known attacks rely upon JVM-internal XSLT code that has been made inaccessible on Java 16 and beyond. Running on a more recent JVM is a mitigating workaround.\n\n### Resources\nThe vulnerabilities and security upgrades are documented in c3p0's manual. Please see c3p0's [Security Note](https://www.mchange.com/projects/c3p0/#security-note) and [Configuring Security](https://www.mchange.com/projects/c3p0/#configuring_security).\n\n### Credits\nmchange-commons-java thanks 4ra1n and unam4 on Github for a proof-of-concept.",
"id": "GHSA-h84g-69h7-mw6v",
"modified": "2026-09-10T03:51:14.278156192Z",
"published": "2026-08-14T19:29:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/swaldman/mchange-commons-java/security/advisories/GHSA-h84g-69h7-mw6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55153"
},
{
"type": "PACKAGE",
"url": "https://github.com/swaldman/mchange-commons-java"
}
],
"schema_version": "1.9.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "mchange-commons-java contains elements susceptible to abuse via JNDI injection and \"deserialization gadgets\""
}