CVE-2026-55223: swaldman c3p0 · Deserialization of Untrusted Data
Affects swaldman c3p0Source CVE Database V5
Not known to be exploited · CVSS 6.3 Medium : upgrade to 0.14.0 when convenient.
Data as of 13 Nov 2026, 23:54 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.14.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 1 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 13 Nov 2026.
What to do
Upgrade c3p0 and com.mchange/c3p0 to 0.14.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| swaldmanc3p0 | Affected
| Fixed in
|
Mavencom.mchange/c3p0pkg:maven/com.mchange/c3p0Other threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Upgrade c3p0 to version 0.14.0 or later, where this deserialization vulnerability is fixed. No other specific mitigations are indicated. Patch status is not explicitly stated as 'official-fix' but the fix is included in version 0.14.0. Users should verify they are running version 0.14.0 or newer to mitigate this issue.
Description
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.