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](https://www.mchange.com/projects/c3p0/#configuring_security). ### 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](https://mogwailabs.de/en/blog/2025/02/c3p0-you-little-rascal/) [c3p0 documentation, security note](https://www.mchange.com/projects/c3p0/#security-note) [c3p0 documentation, configuring security](https://www.mchange.com/projects/c3p0/#configuring_security)
02 / AFFECTED SOFTWARE
Affected packages
32 explicit affected versions
31 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
### 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](https://www.mchange.com/projects/c3p0/#configuring_security). ### 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](https://mogwailabs.de/en/blog/2025/02/c3p0-you-little-rascal/) [c3p0 documentation, security note](https://www.mchange.com/projects/c3p0/#security-note) [c3p0 documentation, configuring security](https://www.mchange.com/projects/c3p0/#configuring_security)
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.
05 / REFERENCES
Further evidence
- https://github.com/swaldman/mchange-commons-java
- https://github.com/swaldman/mchange-commons-java/security/advisories/GHSA-m2cm-222f-qw44
- https://mogwailabs.de/en/blog/2025/02/c3p0-you-little-rascal
- https://nvd.nist.gov/vuln/detail/CVE-2026-27727
- https://www.mchange.com/projects/c3p0/#configuring_security
- https://www.mchange.com/projects/c3p0/#security-note
- https://access.redhat.com/errata/RHSA-2026:14873
- https://access.redhat.com/errata/RHSA-2026:14874
- https://access.redhat.com/errata/RHSA-2026:18054
- https://access.redhat.com/errata/RHSA-2026:18055
- https://access.redhat.com/errata/RHSA-2026:18059
- https://access.redhat.com/errata/RHSA-2026:34365
- https://access.redhat.com/errata/RHSA-2026:3890
- https://access.redhat.com/errata/RHSA-2026:4285
- https://access.redhat.com/security/cve/CVE-2026-27727
- https://bugzilla.redhat.com/show_bug.cgi?id=2442671
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/27xxx/CVE-2026-27727.json
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-27727.json