CVE-2026-55153

Description

A flaw was found in mchange-commons-java, a Java utility library. This vulnerability allows a remote attacker to achieve arbitrary code execution through Java Naming and Directory Interface (JNDI) injection. The library's JNDI ObjectFactory can construct objects of arbitrary classes and initialize properties, which can be exploited by malicious JNDI Reference objects. This could lead to an attacker executing unauthorized code within the application's security domain.

Statement

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 for certain classes enables JNDI injection and deserialization gadgets. The problem is aggravated by the library's ReferenceIndirector, through which malicious JNDI Reference objects can be smuggled wherever an application reads a Java-serialized object.

Exploitation requires either: (1) an attacker-controllable JNDI lookup name reaching a naming context where the vulnerable ObjectFactory is registered, or (2) a deserialization entry point accepting untrusted Java objects, where ReferenceIndirector serves as a gadget class (similar to Log4Shell-style JNDI injection). All affected Red Hat products ship vulnerable versions (< 0.6.0) of mchange-commons-java as a transitive runtime dependency of c3p0 and Hibernate connection pooling.

Mitigation

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.

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score7.5N/A7.1
Attack VectorNetworkN/AAdjacent Network
Attack ComplexityHighN/AHigh
Privileges RequiredLowN/ALow
User InteractionNoneN/ANone
ScopeUnchangedN/AUnchanged
ConfidentialityHighN/AHigh
Integrity ImpactHighN/AHigh
Availability ImpactHighN/AHigh

Vector

Red Hat: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

cve.org: CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Understanding the Weakness (CWE)

Integrity

Technical Impact: Modify Application Data; Unexpected State

Attackers can modify unexpected objects or data that was assumed to be safe from modification. Deserialized data or code could be modified without using the provided accessor functions, or unexpected functions could be invoked.

Availability

Technical Impact: DoS: Resource Consumption (CPU)

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.

Other

Technical Impact: Varies by Context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation. One example is attackers using gadget chains to perform unauthorized actions, such as generating a shell.

Frequently Asked Questions

Want to get errata notifications? Sign up here.