Multiple Vulnerabilities in mchange-commons-java

The mchange-commons-java library, commonly used as a dependency for the c3p0 JDBC connection pool, contained multiple vulnerabilities in its com.mchange.v2.naming.JavaBeanObjectFactory class and ReferenceIndirector mechanism. Versions prior to 0.5.0 allowed BinaryRefAddress elements to be interpreted as Java-serialized objects, enabling the execution of arbitrary code via deserialization gadget chains if libraries like commons-collections are present on the classpath.

Furthermore, versions prior to 0.6.0 permitted the JavaBeanObjectFactory to instantiate arbitrary classes and set properties. Attackers could leverage this via JNDI injection to perform actions such as SSRF (e.g., triggering HTTP requests via JEditorPane) or remote code execution. The ReferenceIndirector mechanism further facilitated these attacks by allowing malicious JNDI Reference objects to be smuggled through serialized data. These issues were addressed in version 0.6.0 by imposing class whitelisting, disabling deserialization support in the ObjectFactory by default, and disabling the ReferenceIndirector.

Impact

The vulnerability impacts any Java application utilizing mchange-commons-java versions below 0.6.0, particularly those using the c3p0 connection pool. If exploited, an attacker could achieve remote code execution on the application server or perform server-side request forgery (SSRF). The success of deserialization-based RCE depends on the presence of vulnerable gadget chains within the application's classpath, while JNDI injection-based SSRF can affect environments regardless of secondary gadget availability.

Recommendation

• Upgrade mchange-commons-java to version 0.6.0 or higher.
• Update c3p0 to version 0.14.0 or higher, which includes the patched mchange-commons-java library transitively.
• If immediate patching is not possible, implement rigorous Java serialization filters (JEP 290/394) to block the deserialization of untrusted classes.
• Migrate to JVM version 16 or newer, as this makes internal JVM-based XSLT gadget chains inaccessible.
• Audit application classpaths to identify and remove unnecessary libraries containing known deserialization gadgets (e.g., commons-beanutils, commons-collections).