CVE-2026-55223: Explicit BeanInfo Generation Removes c3p0 Deserialization Gadget Surface

Vulnerability

CVE-2026-55223 describes a deserialization gadget chain in c3p0 prior to 0.14.0 where JavaBeans introspection can invoke accessor methods such as getConnection() or getPooledConnection() on deserialized DataSource-like objects. In c3p0, those accessors are not inert metadata getters; they can initiate JDBC activity or JNDI resolution, which turns bean property discovery into a code-execution primitive when attacker-controlled objects or URLs are present. The CVE record and related context identify remote code execution through malicious JDBC URLs or JNDI lookups during deserialization-driven introspection rather than through normal application use of the pool itself.

The root issue is that JavaBeans property discovery treats methods following getter conventions as bean properties unless explicit BeanInfo metadata overrides that behavior. For c3p0 DataSource implementations, properties corresponding to live connection acquisition are unsafe to expose to generic introspection because the introspector may call or model them in contexts reachable from deserialization gadget chains.

Relevant references: NVD, CVE.org, and the upstream patch commit 7b022c4b6694dabc6204254dc917af9c38f2cb27.

Patch

The patch introduces a dedicated generator, C3P0BeanInfoGen, to produce explicit BeanInfo classes for c3p0 bean types. The generator excludes bean properties by both name and type:

Set tmp0 = new HashSet();
tmp0.add("connection");
tmp0.add("pooledConnection");
excludedPropertyNames = Collections.unmodifiableSet(tmp0);

Set tmp1 = new HashSet();
tmp1.add( java.sql.Connection.class );
tmp1.add( javax.sql.PooledConnection.class );
excludedPropertyTypes = Collections.unmodifiableSet(tmp1);

This is the key security control: explicit BeanInfo metadata prevents JavaBeans introspection from surfacing dangerous connection-acquisition accessors as bean properties. The build is also changed to generate and compile these BeanInfo classes and package them into the main jar, ensuring java.beans.Introspector can find them at runtime:

object beanInfo extends Gen {
    override def moduleDeps = Seq(build)
    override def mainClass   = Task { Some("com.mchange.v2.c3p0.beaninfo.C3P0BeanInfoGen") }
}
...
Jvm.createJar(
  jar        = out,
  inputPaths = (Seq(compile().classes, beanInfoBin.compile().classes) ++ resources()).map(_.path).filter(os.exists),
  manifest   = manifest()
)

The generated BeanInfo coverage is explicitly wired for these classes in the build: DriverManagerDataSource, PoolBackedDataSource, ComboPooledDataSource, WrapperConnectionPoolDataSource, JndiRefConnectionPoolDataSource, JndiRefForwardingDataSource, and several debug variants. That aligns with the vulnerable surface described in the upstream commit.

Review

Pros

The patch is well-targeted at the actual gadget mechanism. Instead of attempting to harden every connection-producing getter individually, it removes those getters from JavaBeans property exposure, which is the behavior exploited by deserialization gadget chains. Excluding both property names and property types is a strong design choice: it covers canonical getter names like connection and pooledConnection while also catching future or variant accessors returning java.sql.Connection or javax.sql.PooledConnection.

Packaging the generated BeanInfo classes into the shipped jar is also important. A mitigation that exists only in source or tests would be ineffective, but the build changes ensure runtime discovery by java.beans.Introspector. The test-runtime classpath note in the build diff indicates the maintainer understood that BeanInfo presence must match deployed-jar behavior, which increases confidence that the mitigation was validated in realistic conditions.

From a compatibility perspective, this is minimally invasive. It does not change the semantics of legitimate connection acquisition APIs for normal callers; it changes only how generic bean introspection sees those APIs. That reduces regression risk compared with renaming methods or adding runtime guards that could break existing integrations.

Cons

The mitigation is scoped to classes for which explicit BeanInfo is generated. If additional c3p0 classes, subclasses, shaded copies, or downstream wrappers participate in the same introspection pattern without corresponding BeanInfo metadata, the protection may be incomplete. The provided diff shows a fixed list of classes rather than a framework-wide enforcement point.

The patch addresses the JavaBeans introspection gadget surface, but it does not appear to add defensive checks inside the dangerous getters themselves. If another framework, serializer, expression engine, or reflective utility invokes getConnection() or getPooledConnection() directly outside JavaBeans property discovery, this patch would not stop that path. That does not contradict the CVE scope, but it limits the breadth of the hardening.

There is also some reliance on build-time code generation and correct jar assembly. If distributors repackage c3p0 incorrectly, omit generated BeanInfo classes, or consume classes in an unusual classpath layout, the mitigation could be bypassed operationally even if upstream source is fixed.

Verdict

Root-cause.

For the vulnerability as described in NVD and reflected in the upstream change 7b022c4b6694dabc6204254dc917af9c38f2cb27, this patch fixes the root cause of the gadget chain: unsafe exposure of connection-producing accessors to JavaBeans introspection. By supplying explicit BeanInfo that excludes those properties, the patch removes the introspector-mediated trigger rather than merely filtering specific payloads or URLs.

The main residual concern is coverage completeness across all relevant classes and packaging environments, not the quality of the mitigation itself. Assuming version 0.14.0 ships these generated BeanInfo classes for the affected c3p0 DataSource implementations, the patch is a technically sound and appropriately scoped fix for CVE-2026-55223.