{"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\""}