CVE-2026-55153 — mchange-commons-java
HIGHCVE-2026-55153 is a high-severity (CVSS 7.1) CWE-470 vulnerability in com.mchange:mchange-commons-java. A fix is available for com.mchange:mchange-commons-java — see the affected versions and patch details below.
mchange-commons-java contains elements susceptible to abuse via JNDI injection and "deserialization gadgets"
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-55153.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-55153 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,205 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
com.mchange:mchange-commons-javaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.)
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 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.)
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.mchange:mchange-commons-java | all versions | 0.6.0com.mchange:mchange-commons-java:0.6.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.mchange:mchange-commons-java, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update com.mchange:mchange-commons-java to 0.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-55153 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A flaw was found in mchange-commons-java, a Java utility library primarily used as a dependency of the c3p0 JDBC connection pool. Prior to version 0.6.0, the library's JNDI ObjectFactory implementation (JavaBeanObjectFactory) will construct objects of arbitrary classes and initialize JavaBean-style properties, which…
Upgrading to mchange-commons-java >= 0.6.0 is strongly recommended. Most applications that include 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 — upgrading to c3p0 >= 0.14.0 will bring in a patched mchange-commons-java transitively. As a general hardening measure, applications should avoid deserializing untrusted Java objects, and restrict JNDI lookups to trusted naming contexts only.Source: Red Hat security advisory for CVE-2026-55153 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat build of Apache Camel 4.18.3 for Spring Boot 3.5.16 | mchange-commons-java | RHSA-2026:54622 |
Frequently Asked Questions
Is CVE-2026-55153 in your dependencies?
Find it across Maven, including transitive dependencies.