CVE-2026-55223

Description

A flaw was found in c3p0, a JDBC Connection pooling library. This vulnerability allows a remote attacker to potentially execute arbitrary code by crafting a malicious data source object. When an application deserializes this object and automatically resolves its properties, it can trigger vulnerable JDBC drivers. This requires specific conditions, including the presence of a susceptible JDBC driver and a mechanism for automatic property resolution during deserialization.

Statement

A flaw was found in c3p0. Prior to version 0.14.0, c3p0's DataSource and ConnectionPoolDataSource implementations expose getConnection() and getPooledConnection() as JavaBean properties. During deserialization, carrier libraries such as Apache Commons BeanUtils automatically invoke these getters, which can trigger calls into JDBC drivers. An attacker who can deliver a crafted serialized object to an application could exploit this to achieve remote code execution.

Successful exploitation requires all of the following prerequisites to be met:

  1. c3p0 < 0.14.0 on the application classpath
  2. A vulnerable JDBC driver on the classpath
  3. A carrier library that auto-reads JavaBean properties during deserialization (e.g., commons-beanutils with a Comparator in a sorted collection)
  4. A deserialization entry point that processes attacker-controlled data (e.g., via RMI, JMX, or HTTP)

This is a gadget chain attack where c3p0 provides one essential component. Removing any single prerequisite from the classpath prevents exploitation.

Mitigation

Any of the following can reduce the risk or render exploitation not-feasible:
- Run applications on Java 16 or later, which restricts reflective access and partially blocks the JavaBean property lookup step of the attack chain.
- Remove Apache Commons BeanUtils from the classpath if it is not required, eliminating the most common deserialization carrier.
- Ensure the application does not deserialize untrusted input from network sources.

Red Hat recommends updating c3p0 to version 0.14.0 or later when a fix is available, which adds explicit BeanInfo classes to exclude the dangerous properties from JavaBean introspection.

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).

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score7.5N/AN/A
Attack VectorNetworkN/AN/A
Attack ComplexityHighN/AN/A
Privileges RequiredLowN/AN/A
User InteractionNoneN/AN/A
ScopeUnchangedN/AN/A
ConfidentialityHighN/AN/A
Integrity ImpactHighN/AN/A
Availability ImpactHighN/AN/A

Vector

Red Hat: CVSS:3.1/AV:N/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.