CVE-2026-55153

### 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`](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.) ### Patches 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 com