CVE-2026-55223
Impact
The JDBC spec defines the interface DataSource, with a method called getConnection(), and ConnectionPoolDataSource, with a method called getPooledConnection(). These methods are potentially dangerous. One way or another they trigger calls into JDBC drivers, which themselves are complicated, flexible tools which may be, and in practice sometimes have proven to be, susceptible to abuse.
Unfortunately, the JavaBean framework treats methods of this form, getXXX(), as JavaBean "properties", which JavaBean-related libraries often presume represent quick, safe-to-look-up, state or configuration.
Attackers therefore can construct malicious DataSource objects — objects whose calls to getConnection() or getPooledConnection() would trigger attacks via vulnerable JDBC drivers — and bundle them in contexts that automatically look up bean properties on deserialization. If an attacker can smuggle such an object in serialized form to a location from which an application will deserialize it, an attack is triggered.
It's not easy. It requires that a susceptible JDBC DataSource or ConnectionPoolDataSource be available on the application CLASSPATH, along with a susceptible JDBC driver, and a carrier that will automatically look up JavaBean properties on deserialization. In practice, the most common such carrier is the composition of a collection and a Comparator implementation that sorts based on JavaBean properties from Apache commons-beanutils.
But c3p0 prior to 0.14.0 offered the susceptible JDBC DataSource or ConnectionPoolDataSource, supplying an essential component of the trigger.
Patches
c3p0 versions 0.14.0 and above no longer participate in this class of attack, because they include explicit BeanInfo classes which exclude connection and pooledConnection from the list of "introspected" JavaBean properties. Since getConnection() and getPooledConnection() no longer define JavaBean properties, classes that promiscuously read JavaBean properties do not call them, and
CSIRTS triage
- What
- c3p0 is vulnerable to remote code execution via maliciously crafted serialized objects and JNDI references.
- Who is affected
- Applications using c3p0 connection pooling library that deserialize untrusted data.
- Urgency
- Critical; remote code execution is exploitable without authentication and can bypass security restrictions or cause denial of service.
- Action
- Update c3p0 to a patched version addressing CVE-2026-55223, CVE-2026-55153, CVE-2026-27830, and CVE-2026-27727.
AI-assisted analysis generated from the source advisory — verify against the original.
⚡ Watch CVE-2026-55223
Get an email if CVE-2026-55223 is added to CISA KEV, gains public exploit code, or a new advisory cites it — max one per day, one-click unsubscribe.
Exploitation outlook
- Low exploitation risk0.28% 30-day exploitation probability — currently an unlikely target, but scores change as exploit code circulates. Riskier than 21% of all EPSS-scored CVEs.
Advisory coverage (3)
- unknownUSN-8642-1: c3p0 vulnerabilitiesubuntu · 2026-08-18
- mediumGHSA-w6w4-rjh9-9r58: c3p0 can, in combination with other libraries, compose to a "sink" for deserialization ga…ghsa · 2026-07-23
- unknownCVE-2026-55223: c3p0 is a JDBC Connection pooling library. In versions prior to 0.14.0, c3p0 in combination wi…nvd · 2026-06-30
External references
Embed the live status
— this badge updates automatically when the KEV or exploit status changes. How to embed it →
[](https://www.csirts.com/cve/CVE-2026-55223)