Findings

CVE-2026-27830

c3p0, a JDBC Connection pooling library, is vulnerable to attack via maliciously crafted Java-serialized objects and instances.

Published Feb 26, 2026 · updated Sep 14, 2026

c3p0, a JDBC Connection pooling library, is vulnerable to attack via maliciously crafted Java-serialized objects and instances. Several c3p0 implementations have a property called which conceptually represents a . Prior to v0.12.0, that property was maintained as a hex-encoded serialized object. Any attacker able to reset this property, on an existing or via maliciously crafted serialized objects or instances could be tailored execute unexpected code on the application's . The danger of this vulnerability was strongly magnified by vulnerabilities in c3p0's main dependency, mchange-commons-java. This library includes code that mirrors early implementations of JNDI functionality, including ungated support for remote values. Attackers could set c3p0's hex-encoded serialized objects that include objects "indirectly serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded objects could provoke download and execution of malicious code from a remote . Although hazard presented by c3p0's vulnerabilites are exarcerbated by vulnerabilities in mchange-commons-java, use of Java-serialized-object hex as the format for a writable Java-Bean property, of objects that may be exposed across JNDI interfaces, represents a serious independent fragility. The property of c3p0 classes has been reimplemented to use a safe CSV-based format, rather than rely upon potentially dangerous Java object deserialization. c3p0-0.12.0+ and above depend upon mchange-commons-java 0.4.0+, which gates support for remote values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.