What is the CVSS score of CVE-2026-55153?

CVE-2026-55153 has a CVSS 3.1 base score of 7.1 (High). CVSS vector: CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

Which versions of mchange-commons-java are affected by CVE-2026-55153?

mchange-commons-java, a critical library underpinning database connection management in Java applications, exposes organizations to remote code execution through JNDI injection attacks in…. A patch is available.

How to fix or mitigate CVE-2026-55153?

Within 24 hours: Scan all Java application repositories and container images to identify use of mchange-commons-java and c3p0 libraries, documenting current versions. Within 7 days: Classify applications by exploitation risk (those handling untrusted data or remote JNDI references); escalate high-risk applications to application security teams; request patch timeline from mchange vendors. Within 30 days: Deploy compensating controls listed below; establish upgrade readiness plan for patched mchange-commons-java once vendor releases a fix.

mchange-commons-java CVE-2026-55153

EUVD-2026-41135 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-07-01 GitHub_M

GHSA-h84g-69h7-mw6v

Java Deserialization Red Hat Mchange Commons Java

7.1

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.1 HIGH

AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

8.1 HIGH

Network-reachable when an app deserializes untrusted input (AV:N, PR:N), but requires a viable gadget class and an app path feeding attacker data (AC:H); full impact via JNDI injection.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Adjacent

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Jul 01, 2026 - 22:02 EUVD

Analysis Generated

Jul 01, 2026 - 20:51 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

31 maven packages depend on com.mchange:mchange-commons-java (1 direct, 30 indirect)

Ecosystem-wide dependent count for version 0.6.0.

DescriptionCVE.org

mchange-commons-java is a Java library of shared utility classes used by mchange projects like the c3p0 connection pool. Prior to version 0.6.0, its JNDI ObjectFactory implementation (com.mchange.v2.naming.JavaBeanObjectFactory) will construct objects of arbitrary classes and initialize "JavaBean"-style properties, which for certain classes enables JNDI injection and "deserialization gadgets." Such initialization is unsafe for some classes: for example, setting the contentType property of a Swing JEditorPane to text/html and its text property to HTML containing a stylesheet <link> will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. The problem is aggravated by the library's ReferenceIndirector, through which malicious JNDI Reference objects can be smuggled in for dereferencing wherever an application reads a Java-serialized object. This has been resolved in version 0.6.0.

Articles & Coverage 1

News 3 New Java Vulnerabilities - 3 High Severity, No Active Exploits Jul 02, 2026

AnalysisAI

Insecure JNDI object instantiation in mchange-commons-java before 0.6.0 lets attackers who can influence deserialized data or JNDI Reference resolution coerce the library's JavaBeanObjectFactory into constructing arbitrary classes and setting their JavaBean properties, enabling JNDI injection and deserialization-gadget attacks. Because this library underpins mchange projects such as the c3p0 connection pool, any Java application that deserializes attacker-controlled objects or dereferences untrusted JNDI References through it is exposed; a demonstrated path abuses a Swing JEditorPane to force outbound HTTP requests from a trusted security domain. No public exploit identified at time of analysis and it is not in CISA KEV, so treat it as a patch-now supply-chain issue rather than an actively exploited one.

Technical ContextAI

The affected component is com.mchange.v2.naming.JavaBeanObjectFactory, a JNDI javax.naming.spi.ObjectFactory implementation that reconstructs objects from JNDI References by instantiating the referenced class and populating 'JavaBean'-style setter properties. This is a classic CWE-502 (Deserialization of Untrusted Data) root cause: the factory trusts the class name and property values carried in the Reference/serialized stream and performs unsafe reflective initialization. Certain JDK/library classes have side-effecting setters - the advisory cites javax.swing.JEditorPane, where setting contentType to text/html and text to HTML containing a stylesheet <link> triggers an outbound HTTP GET, effectively SSRF from inside the victim's trust boundary; other classes yield fuller JNDI injection (remote codebase/gadget loading). The library's ReferenceIndirector compounds this by allowing malicious JNDI Reference objects to be smuggled in anywhere the application reads a Java-serialized object, widening the entry points. Per CPE cpe:2.3:a:swaldman:mchange-commons-java, all versions prior to 0.6.0 are affected; the fixed release is 0.6.0.

RemediationAI

Vendor-released patch: 0.6.0 - upgrade mchange-commons-java to 0.6.0 or later, including bumping transitive copies pulled in through c3p0 or other mchange projects (audit your dependency tree with 'mvn dependency:tree' or 'gradle dependencies' since it is frequently transitive). Follow the guidance in GHSA-h84g-69h7-mw6v (https://github.com/swaldman/mchange-commons-java/security/advisories/GHSA-h84g-69h7-mw6v). Where an immediate upgrade is not possible, reduce exposure by ensuring the application never deserializes untrusted Java objects and never resolves JNDI References from attacker-influenced sources; add a JVM serialization filter (java.io.ObjectInputFilter / jdk.serialFilter) to block com.mchange.v2.naming.* and javax.swing.* classes and reject unexpected Reference types, accepting that overly broad filters can break legitimate deserialization. Setting com.sun.jndi.ldap.object.trustURLCodebase and com.sun.jndi.rmi.object.trustURLCodebase to false limits remote-codebase JNDI loading but does not close the JavaBean-property side-effect (SSRF via JEditorPane) path, so it is only a partial mitigation until 0.6.0 is deployed.