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.

Affected: Maven: com.mchange:mchange-commons-java

### 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, config…

Affected: openEuler:24.03-LTS: mchange-commons, openEuler:24.03-LTS-SP1: mchange-commons, openEuler:24.03-LTS-SP2: mchange-commons, openEuler:24.03-LTS-SP3: mchange-commons, openEuler:20.03-LTS-SP4: mchange-commons, openEuler:22.03-LTS-SP4: mchange-commons

General tool, part of c3p0. Security Fix(es):

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.(CVE-2026-27727)

c3p0-0.12.0-1.1 on GA media

python-markdown: denial of service via malformed HTML-like sequences pillow: Pillow: Out-of-bounds Write via Specially Crafted PSD Image pyOpenSSL: DTLS cookie callback buffer overflow com.mchange/mchange-commons-java: mchange-commons-java: Arbitrary code execution via JNDI dereferencing of crafted objects Rails: Active Support: Active Support: Denial of Service via large scientific notation strings

Security update for c3p0 and mchange-commons

Affected: Ubuntu:Pro:16.04:LTS: c3p0, Ubuntu:Pro:20.04:LTS: c3p0, Ubuntu:25.10: c3p0

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.

Ein Angreifer kann mehrere Schwachstellen in Red Hat Build of Debezium for Red Hat Application Foundations ausnutzen, um beliebigen Programmcode auszuführen.