CVE-2026-55153: mchange-commons-java RCE Vulnerability

CVE-2026-55153 Overview

CVE-2026-55153 is a JNDI injection vulnerability in mchange-commons-java, a Java library of shared utility classes used by mchange projects such as the c3p0 connection pool. The flaw resides in the com.mchange.v2.naming.JavaBeanObjectFactory JNDI ObjectFactory implementation. Prior to version 0.6.0, this factory constructs objects of arbitrary classes and initializes JavaBean-style properties, enabling JNDI injection and deserialization gadgets [CWE-470]. The library's ReferenceIndirector compounds the risk by allowing attackers to smuggle malicious JNDI Reference objects into any code path that reads a Java-serialized object. Version 0.6.0 resolves the issue.

Critical Impact
Attackers who can influence JNDI lookups or serialized object streams can trigger arbitrary class instantiation, outbound HTTP requests from trusted security domains, and deserialization gadget chains leading to remote code execution.

Affected Products

mchange-commons-java versions prior to 0.6.0
Applications embedding the c3p0 connection pool that transitively depend on mchange-commons-java
Java applications that deserialize untrusted data using the vulnerable library on the classpath

Discovery Timeline

2026-07-01 - CVE-2026-55153 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-55153

Vulnerability Analysis

The vulnerability stems from unsafe object construction inside com.mchange.v2.naming.JavaBeanObjectFactory. When JNDI resolves a Reference, the factory instantiates the class named in the reference and populates JavaBean-style properties from attacker-controlled values. This general-purpose behavior does not validate class types or property semantics, so any class with side-effect-bearing setters becomes a potential gadget.

The advisory highlights a concrete example using Swing's JEditorPane. Setting the contentType property to text/html and the text property to HTML containing a stylesheet <link> provokes an HTTP GET against an attacker-supplied URL. The request originates from within the victim application's security context, bypassing perimeter controls.

The ReferenceIndirector class widens the attack surface. It allows malicious JNDI Reference objects to be transported through any code path that reads Java-serialized objects. An attacker who controls a serialized payload consumed by the application can trigger JNDI dereferencing without direct access to a JNDI lookup call.

Root Cause

The factory implements the JNDI ObjectFactory contract without restricting instantiable classes or property names. This is a Use of Externally-Controlled Input to Select Classes or Code [CWE-470], commonly referred to as unsafe reflection.

Attack Vector

Exploitation requires an adjacent-network position and low privileges. An attacker supplies a crafted JNDI Reference — directly through a JNDI lookup or indirectly through the ReferenceIndirector embedded in a serialized object stream. The factory then constructs the referenced class and invokes attacker-controlled setters, enabling outbound network requests, deserialization gadget chains, or arbitrary code execution depending on classes present on the classpath.

No verified public exploit code is available at time of publication. See the GitHub Security Advisory for the vendor's technical description.

Detection Methods for CVE-2026-55153

Indicators of Compromise

Unexpected outbound HTTP or LDAP requests from Java application processes to unfamiliar hosts, particularly requests originating during deserialization or JNDI resolution.
Presence of mchange-commons-java versions earlier than 0.6.0 in application dependency trees, verifiable via mvn dependency:tree or equivalent build tooling.
Log entries referencing com.mchange.v2.naming.JavaBeanObjectFactory or ReferenceIndirector during request handling.

Detection Strategies

Perform Software Composition Analysis (SCA) across build artifacts and running containers to identify vulnerable mchange-commons-java versions transitively pulled by c3p0.
Instrument JVM security managers or Java agents to log invocations of javax.naming.spi.ObjectFactory.getObjectInstance and flag calls resolving to JavaBeanObjectFactory.
Correlate Java process network telemetry with deserialization events to surface JNDI-triggered egress.

Monitoring Recommendations

Alert on Java processes initiating DNS, LDAP, or HTTP connections to non-allowlisted destinations, especially those tied to serialized payload ingestion endpoints.
Monitor application logs for stack traces containing com.mchange.v2.naming frames during request processing.
Track dependency updates in CI/CD pipelines and block builds that pin mchange-commons-java below 0.6.0.

How to Mitigate CVE-2026-55153

Immediate Actions Required

Upgrade mchange-commons-java to version 0.6.0 or later across all applications, including transitive dependencies pulled through c3p0.
Audit application endpoints that accept or deserialize Java objects and restrict them to authenticated, trusted sources.
Enforce egress filtering on Java application hosts to block unauthorized outbound HTTP and LDAP traffic.

Patch Information

The maintainer resolved the issue in mchange-commons-java version 0.6.0. Details are documented in the GitHub Security Advisory GHSA-h84g-69h7-mw6v. Rebuild and redeploy dependent applications after updating the version constraint in Maven, Gradle, or equivalent build files.

Workarounds

If immediate upgrade is not feasible, remove or disable code paths that resolve untrusted JNDI references or deserialize untrusted Java objects.
Configure com.sun.jndi.ldap.object.trustURLCodebase and com.sun.jndi.rmi.object.trustURLCodebase to false to reduce JNDI attack surface, though this does not fully mitigate JavaBeanObjectFactory abuse.
Apply a Java Security Manager policy or ObjectInputFilter allowlist to prevent instantiation of gadget classes such as javax.swing.JEditorPane from deserialized data.

bash

# Maven dependency override to force patched version
mvn versions:use-dep-version -Dincludes=com.mchange:mchange-commons-java -DdepVersion=0.6.0 -DforceVersion=true

# Verify the resolved version in the dependency tree
mvn dependency:tree -Dincludes=com.mchange:mchange-commons-java