CVE-2026-27727 is a critical flaw (CVSS 9.8) in mchange-commons-java, a Java utility library used by c3p0. Its own JNDI reference handling can download and run remote code. Version 0.4.0 gates that behaviour with restrictive defaults, and the vendor lists no workaround, so upgrade.
What's affected
mchange-commons-java before 0.4.0. The advisory says earlier versions should be avoided on application classpaths. Libraries such as c3p0, the Java connection pooling library, resolve references through this code, so applications that use c3p0 can be affected without ever naming mchange-commons-java.
The advisory says there are no known workarounds. The KEV flag is false.
How to check if you're exposed
Look for the library in your dependency tree, since it is usually an indirect dependency.
# Maven
mvn dependency:tree -Dincludes=com.mchange:mchange-commons-java
# Gradle
./gradlew dependencies | grep mchange
Also check packaged applications. Fat jars and application servers often bundle old copies, so check the files in deployed artifacts as well as the build files.
Rank what you find by whether the application can be made to read an untrusted serialized object or reference. You can paste a build file into the free in-browser dependency scan to list the affected versions.
What to do now
- Upgrade mchange-commons-java to 0.4.0 or later. If c3p0 brings it in, update c3p0 to a release that depends on a fixed version.
- If you pin versions, use dependency management or an override to force the fixed library.
- Read the c3p0 security notes on configuring security, linked from the advisory.
- Make sure the Java runtime is current, but do not treat it as a fix, because this library carries its own implementation.
- Reduce what your application deserializes from untrusted sources.
- Rebuild and redeploy every service that bundles the library.
Why it matters
The record lists deserialization of untrusted data, CWE-502, and injection, CWE-74. JNDI is a Java directory lookup mechanism. Years ago, loading classes from a remote location through JNDI references became a well known route to remote code execution, and the JDK disabled it by default behind a system property that defaults to false.
The advisory explains why that is not enough. This library includes its own independent copy of the dereferencing logic, so it keeps working even when the JDK is hardened. Any library that resolves references through it, such as c3p0, can be provoked to download and run code.
Version 0.4.0 mirrors the JDK change. The JNDI functionality is gated by configuration parameters that default to restrictive values. The lesson is that a hardened runtime does not protect you from a library that re-implements the dangerous part.
This is a good case for reachability analysis. Many applications have the library on the classpath without ever resolving untrusted references. Knowing which services actually reach the dangerous call lets you fix those first.
Where this library hides
mchange-commons-java is the kind of dependency teams never choose directly. It arrives with c3p0, which arrives with an ORM or an application server module, which arrives with your application. A search of your own build files may show nothing, while the deployed artifact carries a copy inside a fat jar or an application server library folder.
So check at three levels. Look at the source dependency tree. Look at the built artifact, including nested archives. Look at what the application server provides on its own classpath, since a container can supply the library even if your build does not.
Reading the version number
The fixed line starts at 0.4.0. The advisory says anything older should be avoided on application classpaths, and that no workarounds are known. That wording is stronger than the usual advice to upgrade soon. If you find an older copy that you cannot update right away, treat that service as one to isolate: limit what it can reach on the network, and reduce its ability to load content from remote locations.
Using reachability to order the work
Not every service with the library can be driven into the vulnerable path. The attack needs the application to read a crafted reference or serialized object, so services that never deserialize data from outside carry less immediate risk than services that read objects from queues, caches or user uploads. Reachability analysis shows which of your services actually call into the code in question. Fix those first, then work through the rest on the normal schedule.
Related reading in the advisory
The advisory links background on how c3p0 handled this issue and the c3p0 documentation on configuring security. If you run c3p0, read the security note there, since the library's own settings determine what remote resolution is allowed.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does upgrading Java fix this?
No. The advisory says the library carries its own implementation, so you need the library update.
Sources
Last reviewed: 19 October 2026.
