CVE-2026-55153High· 7.1▾ Twilightmchange-commons-java contains elements susceptible to abuse via JNDI injection and "deserialization gadgets"
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 39.1 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Aug 14.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.6%
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.)
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.)
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.
com.mchange:mchange-commons-java < 0.6.0Upgrade to a patched release:
com.mchange:mchange-commons-java 0.6.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-55223Mediumc3p0 can, in combination with other libraries, compose to a "sink" for deserialization gadgets
CVE-2026-55559Critical· 9.8Yamcs is a mission control framework
CVE-2026-63337HighThe RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes
CVE-2026-62379Critical· 9.8Open Access Management (OpenAM) is an access management solution
CVE-2026-27727Critical· 9.8mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote `factoryClassLocation` values, by which code can be downloaded and invoked…
CVE-2026-42027Critical· 9.8Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader Versions Affected: before 1.9.5, before 2.5.9, before 3.0.0-M3 Description: The ExtensionLoader.instantiateExtension(Class, String) method loa…