CVE-2026-27727: mchange-commons-java: Remote Code Execution via JNDI Reference Resolution
Impact mchange-commons-java includes code that mirrors early implementations of JNDI functionality, including support for remote factoryClassLocation values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted jaxax.naming.Reference or serialized object, they can provoke the download and execution of malicious code.
Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to false, com.sun.jndi.ldap.object.trustURLCodebase. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened.
Patches Mirroring the JDK patch, mchange-commons-java's JNDI functionality is now gated by configuration parameters that default to restrictive values. Those parameters are documented here.
Workarounds No. Users should upgrade to mchange-commons-java >= 0.4.0. Earlier versions should be avoided on application CLASSPATHs.
References
c3p0, you little rascal — Hans-Martin Münch c3p0 documentation, security note c3p0 documentation, configuring security
Other sources
mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote factoryClassLocation values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted jaxax.naming.Reference or serialized object, they can provoke the download and execution of malicious code. Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to false, com.sun.jndi.ldap.object.trustURLCodebase. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened. Mirroring the JDK patch, mchange-commons-java's JNDI functionality is gated by configuration parameters that default to restrictive values starting in version 0.4.0. No known workarounds are available. Versions prior to 0.4.0 should be avoided on application CLASSPATHs.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/com.mchange:mchange-commons-javato a version that resolves this vulnerability.Fixed in 0.4.0 - Upgrade
Upgrade
mchange-commons-javato a version that resolves this vulnerability.Fixed in >= 0.4.0 - Configuration
Ensure mchange-commons-java is at version 0.4.0 or later so its JNDI functionality is gated by configuration parameters that default to restrictive values; avoid using versions prior to 0.4.0 on the application CLASSPATH.
mchange-commons-java JNDI functionality gated configuration parameters (defaults to restrictive values starting in version 0.4.0) = default restrictive values - Configuration
Set the System property com.sun.jndi.ldap.object.trustURLCodebase to false (it defaults to false in the hardened JDK behavior) to disable trust of remote codebase in JNDI object reference resolution.
JDK JNDI dereferencing (mirrored behavior) com.sun.jndi.ldap.object.trustURLCodebase = false
Event History
Frequently Asked Questions
What is the severity of CVE-2026-27727?
CVE-2026-27727 is classified with a high severity due to its potential for remote code execution.
How do I fix CVE-2026-27727?
To fix CVE-2026-27727, upgrade to version 0.4.0 or later of mchange-commons-java.
What applications are affected by CVE-2026-27727?
CVE-2026-27727 affects applications utilizing mchange-commons-java versions prior to 0.4.0.
What are the potential consequences of exploiting CVE-2026-27727?
Exploiting CVE-2026-27727 may lead to unauthorized remote code execution in affected applications.
Is there a workaround for CVE-2026-27727 before applying the fix?
A recommended workaround for CVE-2026-27727 is to disable JNDI functionality if it is not strictly necessary.