c3p0 - Debian Package Tracker

general

source: c3p0 (main)
version: 0.9.1.2-11
maintainer: Debian Java Maintainers (archive) (DMD)
uploaders: Varun Hiremath [DMD] – Emmanuel Bourg [DMD]
arch: all
std-ver: 4.7.2
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 0.9.1.2-10
oldstable: 0.9.1.2-10.1~deb12u1
stable: 0.9.1.2-10.1
testing: 0.9.1.2-11
unstable: 0.9.1.2-11

versioned links

0.9.1.2-10: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
0.9.1.2-10.1~deb12u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
0.9.1.2-10.1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
0.9.1.2-11: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

libc3p0-java
libc3p0-java-doc

action needed

A new upstream version is available: 0.9.5.5.src high

A new upstream version 0.9.5.5.src is available, you should consider packaging it.

Created: 2026-03-02 Last update: 2026-08-07 04:30

2 security issues in trixie high

There are 2 open security issues in trixie.

1 important issue:

CVE-2026-55223: 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.

1 issue left for the package maintainer to handle:

CVE-2026-27830: (needs triaging) c3p0, a JDBC Connection pooling library, 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 serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. 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 `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` 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 `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.

You can find information about how to handle this issue in the security team's documentation.

Created: 2026-02-27 Last update: 2026-08-06 10:30

2 security issues in sid high

There are 2 open security issues in sid.

2 important issues:

CVE-2026-27830: c3p0, a JDBC Connection pooling library, 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 serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. 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 `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` 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 `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.
CVE-2026-55223: 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.

Created: 2026-02-27 Last update: 2026-08-06 10:30

2 security issues in forky high

There are 2 open security issues in forky.

2 important issues:

CVE-2026-27830: c3p0, a JDBC Connection pooling library, 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 serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. 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 `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` 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 `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.
CVE-2026-55223: 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.

Created: 2026-02-27 Last update: 2026-08-06 10:30

3 security issues in bullseye high

There are 3 open security issues in bullseye.

1 important issue:

CVE-2026-55223: 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.

2 issues postponed or untriaged:

CVE-2019-5427: (needs triaging) 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.
CVE-2026-27830: (postponed; to be fixed through a stable update) c3p0, a JDBC Connection pooling library, 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 serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. 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 `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` 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 `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.

Created: 2026-02-27 Last update: 2026-08-06 10:30

2 security issues in bookworm high

There are 2 open security issues in bookworm.

1 important issue:

CVE-2026-55223: 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.

1 issue postponed or untriaged:

CVE-2026-27830: (postponed; to be fixed through a stable update) c3p0, a JDBC Connection pooling library, 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 serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. 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 `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` 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 `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0.

Created: 2023-06-10 Last update: 2026-08-06 10:30

debian/patches: 3 patches with invalid metadata, 2 patches to forward upstream high

Among the 5 debian patches available in version 0.9.1.2-11 of the package, we noticed the following issues:

3 patches with invalid metadata that ought to be fixed.
2 patches where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2023-02-26 Last update: 2025-09-05 09:30

2 new commits since last upload, is it time to release? normal

vcswatch reports that this package seems to have new commits in its VCS but has not yet updated debian/changelog. You should consider updating the Debian changelog and uploading this new version into the archive.

Here are the relevant commit logs:

commit e25689f475fcc1307836dcd31a850c865b5686b7
Author: Bastien Roucariès <rouca@debian.org>
Date:   Wed Aug 5 19:45:01 2026 +0200

    Use modern uscan copyright

commit bd1ce55165fa4dbbb1024ff852ac27c58eeac410
Author: Bastien Roucariès <rouca@debian.org>
Date:   Wed Aug 5 19:43:46 2026 +0200

    Use new upstream

https://salsa.debian.org/api/v4/projects/java-team%2Fc3p0 API request failed: 401 Unauthorized at /srv/qa.debian.org/data/vcswatch/vcswatch line 410.

Created: 2026-08-05 Last update: 2026-08-05 19:01

lintian reports 4 warnings normal

Lintian reports 4 warnings about this package. You should make the package lintian clean getting rid of them.

Created: 2025-09-05 Last update: 2025-09-05 04:31

Standards version of the package is outdated. wishlist

The package should be updated to follow the last version of Debian Policy (Standards-Version 4.7.4 instead of 4.7.2).

Created: 2025-12-23 Last update: 2026-03-31 15:01

news

[rss feed]

[2026-05-04] Accepted c3p0 0.9.1.2-10.1~deb12u1 (source) into oldstable-proposed-updates (Debian FTP Masters) (signed by: Adrian Bunk)
[2025-09-11] c3p0 0.9.1.2-11 MIGRATED to testing (Debian testing watch)
[2025-09-04] Accepted c3p0 0.9.1.2-11 (source) into unstable (Alexandre Detiste)
[2025-04-09] c3p0 0.9.1.2-10.1 MIGRATED to testing (Debian testing watch)
[2025-04-04] Accepted c3p0 0.9.1.2-10.1 (source) into unstable (Bastian Germann) (signed by: bage@debian.org)
[2019-01-03] Accepted c3p0 0.9.1.2-9+deb9u1 (source) into proposed-updates->stable-new, proposed-updates (Markus Koschany)
[2018-12-31] c3p0 0.9.1.2-10 MIGRATED to testing (Debian testing watch)
[2018-12-28] Accepted c3p0 0.9.1.2-9+deb8u1 (source all) into oldstable (Markus Koschany)
[2018-12-25] Accepted c3p0 0.9.1.2-10 (source) into unstable (Markus Koschany)
[2014-01-22] c3p0 0.9.1.2-9 MIGRATED to testing (Debian testing watch)
[2014-01-17] Accepted c3p0 0.9.1.2-9 (source all) (Markus Koschany) (signed by: tony mancill)
[2013-08-09] c3p0 0.9.1.2-8 MIGRATED to testing (Debian testing watch)
[2013-07-30] Accepted c3p0 0.9.1.2-8 (source all) (Emmanuel Bourg) (signed by: tony mancill)
[2012-07-19] c3p0 0.9.1.2-7 MIGRATED to testing (Debian testing watch)
[2012-07-09] Accepted c3p0 0.9.1.2-7 (source all) (Damien Raude-Morvan)
[2012-05-02] c3p0 0.9.1.2-6 MIGRATED to testing (Debian testing watch)
[2012-04-22] Accepted c3p0 0.9.1.2-6 (source all) (tony mancill)
[2010-06-01] c3p0 0.9.1.2-5 MIGRATED to testing (Debian testing watch)
[2010-05-21] Accepted c3p0 0.9.1.2-5 (source all) (Torsten Werner)
[2010-05-14] c3p0 0.9.1.2-4 MIGRATED to testing (Debian testing watch)
[2010-05-03] Accepted c3p0 0.9.1.2-4 (source all) (Torsten Werner)
[2009-09-12] c3p0 0.9.1.2-3 MIGRATED to testing (Debian testing watch)
[2009-09-06] Accepted c3p0 0.9.1.2-3 (source all) (Michael Koch)
[2009-05-18] c3p0 0.9.1.2-2 MIGRATED to testing (Debian testing watch)
[2009-05-07] Accepted c3p0 0.9.1.2-2 (source all) (Varun Hiremath)
[2007-09-27] c3p0 0.9.1.2-1 MIGRATED to testing (Debian testing watch)
[2007-09-16] Accepted c3p0 0.9.1.2-1 (source all) (Varun Hiremath) (signed by: Michael Koch)
[2007-07-21] c3p0 0.9.1.1.dfsg.1-2 MIGRATED to testing (Debian testing watch)
[2007-07-10] Accepted c3p0 0.9.1.1.dfsg.1-2 (source all) (Michael Koch)
[2007-04-22] Accepted c3p0 0.9.1.1.dfsg.1-1 (source all) (Arnaud Vandyck)

bugs [bug history graph]

all: 2
RC: 1
I&N: 0
M&W: 1
F&P: 0
patch: 0

links

homepage
lintian (0, 4)
buildd: logs, reproducibility
popcon
browse source code
other distros
security tracker
debian patches

ubuntu

[Information about Ubuntu for Debian Developers]

version: 0.9.1.2-11