Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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,…
Recommended action: Upgrade to 0.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact c3p0 is vulnerable to attack via maliciously crafted Java-serialized objects and javax.naming.Reference instances. Several c3p0 ConnectionPoolDataSource implementations have a property called userOverridesAsString which conceptually represents a Map<String,Map<String,String. 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 ConnectionPoolDataSource or via maliciously crafted serialized objects or javax.naming.Reference instances could be tailored execute unexpected code on the application's CLASSPATH. 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 factoryClassLocation values. Attackers could set c3p0's userOverridesAsString hex-encoded serialized objects that include objects "indirectly…
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
c3p0 version < 0.9.5.4 may be exploited by a billion laughs attack when loading XML configuration due to missing protections against recursive entity expansion when loading configuration.
Recommended action: Upgrade to 0.9.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
c3p0 0.9.5.2 allows XXE in extractXmlConfigFromInputStream in com/mchange/v2/c3p0/cfg/C3P0ConfigXmlUtils.java during initialization.
Recommended action: Upgrade to 0.9.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.