Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| com.mchange:mchange-commons-java | maven | < 0.6.0 | 0.6.0 |
Miggo AIRoot Cause AnalysisThe vulnerability in mchange-commons-java (CVE-2026-55153) stems from two main components: com.mchange.v2.naming.JavaBeanObjectFactory and com.mchange.v2.naming.ReferenceIndirector.
JavaBeanObjectFactory: This class was responsible for creating objects from JNDI Reference objects. It had two critical flaws:
BinaryRefAddr: Before version 0.5.0, it would deserialize byte arrays from BinaryRefAddr attributes. This exposed the application to Java deserialization attacks if a malicious serialized object (a "gadget chain") was provided in the Reference.Reference's class name field. An attacker could specify a class from the application's classpath that has harmful side effects upon instantiation or when its properties are set, leading to code execution or other impacts.ReferenceIndirector: This class provided a mechanism to serialize Referenceable objects. Before version 0.6.0, it was enabled by default and could be abused to wrap a malicious JNDI Reference inside a serialized object. When this object was later deserialized by an application, the ReferenceIndirector$ReferenceSerialized.getObject method would be called, triggering the JNDI lookup of the malicious Reference.
The patches address these issues by:
BinaryRefAddr in JavaBeanObjectFactory by default in v0.5.0.JavaBeanObjectFactory in v0.6.0, preventing the instantiation of arbitrary classes.ReferenceIndirector mechanism by default in v0.6.0.Therefore, the key vulnerable functions that would appear in a runtime profile during exploitation are com.mchange.v2.naming.JavaBeanObjectFactory.getObjectInstance (the entry point for the JNDI object creation), com.mchange.v2.naming.ReferenceIndirector.indirectForm (for creating the malicious serialized object), and com.mchange.v2.naming.ReferenceIndirector$ReferenceSerialized.getObject (for triggering the attack upon deserialization).
com.mchange.v2.naming.JavaBeanObjectFactory.getObjectInstancesrc/main/java/com/mchange/v2/naming/JavaBeanObjectFactory.java
com.mchange.v2.naming.JavaBeanObjectFactory.getObjectInstancesrc/main/java/com/mchange/v2/naming/JavaBeanObjectFactory.java
com.mchange.v2.naming.ReferenceIndirector.indirectFormsrc/main/java/com/mchange/v2/naming/ReferenceIndirector.java
com.mchange.v2.naming.ReferenceIndirector$ReferenceSerialized.getObjectsrc/main/java/com/mchange/v2/naming/ReferenceIndirector.java
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.)
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.
The vulnerabilities and security upgrades are documented in c3p0's manual. Please see c3p0's Security Note and Configuring Security.
mchange-commons-java thanks 4ra1n and unam4 on Github for a proof-of-concept.