Summary
mchange-commons-java contains elements susceptible to abuse via JNDI injection and "deserialization gadgets"
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 and Configuring Security.
Credits
mchange-commons-java thanks 4ra1n and unam4 on Github for a proof-of-concept.
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 and commons-collections on the application CLASSPATH, objects can be crafted that will execute arbitrary commands on deserialization. (Thanks to Valerio Mulas for a proof-of-concept.)
CVE-2026-55153 has a CVSS score of 7.1 (High). The vector is reachable from an adjacent network, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.6.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.)
Frequently Asked Questions
- What is CVE-2026-55153? CVE-2026-55153 is a high-severity security vulnerability in com.mchange:mchange-commons-java (maven), affecting versions < 0.6.0. It is fixed in 0.6.0.
- How severe is CVE-2026-55153? CVE-2026-55153 has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of com.mchange:mchange-commons-java are affected by CVE-2026-55153? com.mchange:mchange-commons-java (maven) versions < 0.6.0 is affected.
- Is there a fix for CVE-2026-55153? Yes. CVE-2026-55153 is fixed in 0.6.0. Upgrade to this version or later.
- Is CVE-2026-55153 exploitable, and should I be worried? Whether CVE-2026-55153 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-55153 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-55153? Upgrade
com.mchange:mchange-commons-javato 0.6.0 or later.