Copyright © 2012 Red Hat, Inc. All rights reserved. Important 2026-06-30T22:56:55 c3p0: c3p0: Remote code execution via deserialization vulnerability 7.5 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H CWE-502

c3p0 is a JDBC Connection pooling library. In versions prior to 0.14.0, c3p0 in combination with other libraries, can compose to a "sink" for deserialization gadgets. The JDBC spec's DataSource.getConnection() and ConnectionPoolDataSource.getPooledConnection() match the getXXX() form, so JavaBean libraries treat them as "properties" assumed safe while they actually call into JDBC drivers. Attackers can thus craft malicious DataSource objects whose property lookups invoke vulnerable drivers, then smuggle them in serialized form to where an application deserializes and auto-resolves bean properties — triggering the attack. This requires a susceptible DataSource/ConnectionPoolDataSource and JDBC driver on the CLASSPATH, plus a carrier that auto-looks-up JavaBean properties on = deserialization, most commonly a collection paired with an Apache commons-beanutils Comparator that sorts by bean properties. c3p0 supplied that susceptible DataSource/ConnectionPoolDataSource, which was an essential component of the trigger. This issue has been fixed in version 0.14.0.

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.

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. 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. Red Hat build of Apache Camel for Spring Boot 4 Affected c3p0 Red Hat build of Apache Camel - HawtIO 4 Affected c3p0 Red Hat build of Debezium 3 Affected c3p0 Red Hat Fuse 7 Will not fix c3p0 Red Hat JBoss Enterprise Application Platform Expansion Pack Not affected c3p0 Red Hat Satellite 6 Not affected candlepin Red Hat Satellite 6 Not affected satellite:el8/candlepin streams for Apache Kafka 2 Affected c3p0 https://www.cve.org/CVERecord?id=CVE-2026-55223 https://nvd.nist.gov/vuln/detail/CVE-2026-55223 https://github.com/swaldman/c3p0/commit/7b022c4b6694dabc6204254dc917af9c38f2cb27 https://github.com/swaldman/c3p0/security/advisories/GHSA-w6w4-rjh9-9r58