https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 02:25:14 +0000 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/euvd-2026-368447 EUVD-2026-368447 https://cve.radiocsirt.org/vuln/euvd-2026-368447 https://cve.radiocsirt.org/vuln/fkie_cve-2026-27727 <p>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&#39;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.</p> <p>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&#39;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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-27727 https://cve.radiocsirt.org/vuln/ghsa-m2cm-222f-qw44 <p><strong>Affected:</strong> Maven: com.mchange:mchange-commons-java</p> <p>### 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.</p> <p>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.</p> <p>### Patches Mirroring the JDK patch, mchange-commons-java&#39;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).</p> <p>### Workarounds No. Users should upgrade to mchange-commons-java &gt;= 0.4.0. Earlier versions should be avoided on application CLASSPATHs.</p> <p>### References</p> <p>[c3p0, you little rascal &amp;mdash; 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…</p> <p><strong>Affected:</strong> Maven: com.mchange:mchange-commons-java</p> <p>### 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.</p> <p>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.</p> <p>### Patches Mirroring the JDK patch, mchange-commons-java&#39;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).</p> <p>### Workarounds No. Users should upgrade to mchange-commons-java &gt;= 0.4.0. Earlier versions should be avoided on application CLASSPATHs.</p> <p>### References</p> <p>[c3p0, you little rascal &amp;mdash; 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…</p> https://cve.radiocsirt.org/vuln/ghsa-m2cm-222f-qw44 https://cve.radiocsirt.org/vuln/oesa-2026-1690 <p><strong>Affected:</strong> 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</p> <p>General tool, part of c3p0. Security Fix(es):</p> <p>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&amp;apos;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)</p> <p><strong>Affected:</strong> 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</p> <p>General tool, part of c3p0. Security Fix(es):</p> <p>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&amp;apos;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)</p> https://cve.radiocsirt.org/vuln/oesa-2026-1690 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10279-1 <p>c3p0-0.12.0-1.1 on GA media</p> <p>c3p0-0.12.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10279-1 https://cve.radiocsirt.org/vuln/rhsa-2026:14873 <p>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</p> <p>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</p> https://cve.radiocsirt.org/vuln/rhsa-2026:14873 https://cve.radiocsirt.org/vuln/suse-su-2026:0855-1 <p>Security update for c3p0 and mchange-commons</p> <p>Security update for c3p0 and mchange-commons</p> https://cve.radiocsirt.org/vuln/suse-su-2026:0855-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27727 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: c3p0, Ubuntu:Pro:20.04:LTS: c3p0, Ubuntu:25.10: c3p0</p> <p>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&#39;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.</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: c3p0, Ubuntu:Pro:20.04:LTS: c3p0, Ubuntu:25.10: c3p0</p> <p>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&#39;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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27727 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0694 <p>Ein Angreifer kann mehrere Schwachstellen in Red Hat Build of Debezium for Red Hat Application Foundations ausnutzen, um beliebigen Programmcode auszuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Red Hat Build of Debezium for Red Hat Application Foundations ausnutzen, um beliebigen Programmcode auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0694