Update dependency com.mchange:c3p0 to v0.14.0 [SECURITY] (3.31)#4305
Merged
renovate[bot] merged 1 commit intoJul 24, 2026
Merged
Conversation
renovate
Bot
deleted the
renovate/3.31-maven-com.mchange-c3p0-vulnerability
branch
July 24, 2026 01:47
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.12.0→0.14.0c3p0 can, in combination with other libraries, compose to a "sink" for deserialization gadgets
CVE-2026-55223 / GHSA-w6w4-rjh9-9r58
More information
Details
Impact
The JDBC spec defines the interface
DataSource, with a method calledgetConnection(), andConnectionPoolDataSource, with a method calledgetPooledConnection(). 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
DataSourceobjects — objects whose calls togetConnection()orgetPooledConnection()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
DataSourceorConnectionPoolDataSourcebe available on the applicationCLASSPATH, 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 aComparatorimplementation that sorts based on JavaBean properties from Apachecommons-beanutils.But c3p0 prior to 0.14.0 offered the susceptible JDBC
DataSourceorConnectionPoolDataSource, 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
BeanInfoclasses which excludeconnectionandpooledConnectionfrom the list of "introspected" JavaBean properties. SincegetConnection()andgetPooledConnection()no longer define JavaBean properties, classes that promiscuously read JavaBean properties do not call them, and the attack is averted.Workarounds
If users can ensure the safety of all JDBC drivers on the application
CLASSPATH, or that no libraries lie on theCLASSPATHthat can be composed to trigger automatic JavaBean property lookups on deserialization, then this attack is prevented. Nevertheless, given the complexity of modern JDBC drivers and typical Java application transitive dependencies, it is strongly recommended that users upgrade to c3p0 version 0.14.0 or higher.Some versions of this attack are foiled by the stronger encapsulation and restriction of reflective access introduced in Java 16. Running applications on Java 16+ is therefore a potential mitigation.
This attack is described by Hans-Martin Münch in a blog post called "Look Mama, no TemplatesImpl".
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (in timezone Europe/Zurich)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.