Is there a patch available for EUVD-2026-40847?

Yes, a patch is available for EUVD-2026-40847. Update the affected software to the latest version immediately.

c3p0 EUVD-2026-40847

Q: What is the CVSS score of EUVD-2026-40847?

EUVD-2026-40847 has a CVSS 4.0 base score of 6.3 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

| CVE-2026-55223 MEDIUM

Deserialization of Untrusted Data (CWE-502)

2026-06-30 security-advisories@github.com

GHSA-w6w4-rjh9-9r58

Apache Deserialization Red Hat Suse

6.3

CVSS 4.0 · Vendor: github

Severity by source

Vendor (github) PRIMARY

6.3 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.0 CRITICAL

AC:H reflects multiple required classpath and deployment prerequisites; S:C because JDBC driver invocation extends side effects beyond c3p0's own security scope; C/I/A:H reflect RCE potential when a vulnerable driver is present.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 23, 2026 - 23:03 EUVD

Analysis Generated

Jun 30, 2026 - 23:42 vuln.today

CVE Published

Jun 30, 2026 - 23:17 cve.org

MEDIUM 6.3

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

38 maven packages depend on com.mchange:c3p0 (4 direct, 34 indirect)

Ecosystem-wide dependent count for version 0.14.0.

DescriptionCVE.org

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.

AnalysisAI

Remote code execution risk in c3p0 versions prior to 0.14.0 arises from the library serving as an essential 'sink' in Java deserialization gadget chains. c3p0's DataSource and ConnectionPoolDataSource objects conform to JavaBean's getXXX() naming convention, causing commons-beanutils and similar libraries to invoke JDBC connection methods as though they were safe property accessors during deserialization - triggering arbitrary JDBC driver execution under attacker control. No public exploit code or CISA KEV listing has been identified at time of analysis; the CVSS 4.0 vector scores this at 6.3, largely due to the partial attack requirements (AT:P), though real-world impact when prerequisites are met can substantially exceed that rating.

Technical ContextAI

c3p0 is an open-source JDBC connection pooling library (com.mchange:c3p0) that provides DataSource and ConnectionPoolDataSource implementations. The vulnerability (CWE-502, Deserialization of Untrusted Data) exploits a design-level conflict between the JDBC specification's API naming and JavaBean introspection conventions. Methods such as DataSource.getConnection() and ConnectionPoolDataSource.getPooledConnection() follow the getXXX() pattern that JavaBean libraries treat as safe property accessors. When a deserializer auto-resolves bean properties - most commonly through an Apache commons-beanutils BeanComparator that sorts objects by property value during comparison - any c3p0 DataSource present in the payload has its connection methods invoked automatically. This call propagates into the underlying JDBC driver, which may execute exploitable logic (e.g., loading a class, making a network connection, or running arbitrary SQL). c3p0 supplied the susceptible DataSource sink that was an essential link in this gadget chain, closing the loop between the carrier (commons-beanutils) and the JDBC driver's side effects. No CPE strings were provided in the input; the affected artifact is any com.mchange:c3p0 release below 0.14.0.

RemediationAI

The primary fix is to upgrade c3p0 to version 0.14.0 or later, which removes the susceptible DataSource and ConnectionPoolDataSource as gadget sinks. The patch is available at https://github.com/swaldman/c3p0/commit/7b022c4b6694dabc6204254dc917af9c38f2cb27 with the full advisory at https://github.com/swaldman/c3p0/security/advisories/GHSA-w6w4-rjh9-9r58. If immediate patching is not feasible, the most effective compensating control is to restrict Java object deserialization at the application boundary using JEP 290 serialization filters (java.io.ObjectInputFilter), configured to allowlist only known-safe classes and block unknown or untrusted types - this prevents the gadget chain from being assembled regardless of classpath contents, but requires application-level changes and thorough regression testing. As a secondary measure, audit the classpath for known-vulnerable JDBC drivers and remove or upgrade them, since c3p0 alone is a sink but the JDBC driver determines the ultimate exploitable impact. Removing Apache commons-beanutils or pinning it to a version without BeanComparator functionality would also break the carrier mechanism, but may have broader application compatibility implications.