CVE-2019-12406 – cxf: does not restrict the number of message attachments
https://notcve.org/view.php?id=CVE-2019-12406
Apache CXF before 3.3.4 and 3.2.11 does not restrict the number of message attachments present in a given message. This leaves open the possibility of a denial of service type attack, where a malicious user crafts a message containing a very large number of message attachments. From the 3.3.4 and 3.2.11 releases, a default limit of 50 message attachments is enforced. This is configurable via the message property "attachment-max-count". Apache CXF versiones anteriores a la versión 3.3.4 y 3.2.11, no restringe el número de archivos adjuntos presentes en un mensaje dado. • http://cxf.apache.org/security-advisories.data/CVE-2019-12406.txt.asc https://lists.apache.org/thread.html/r36e44ffc1a9b365327df62cdfaabe85b9a5637de102cea07d79b2dbf%40%3Ccommits.cxf.apache.org%3E https://lists.apache.org/thread.html/r92238967ba2783d3ab5a483f2e17f5fdaa8ace98990f69f9e8e15de0%40%3Cissues.cxf.apache.org%3E https://lists.apache.org/thread.html/rabc395b38acb7f2465bfbf0bc16d6e1e95720c89bea87abe8808eeea%40%3Cissues.cxf.apache.org%3E https://lists.apache.org/thread.html/rb2a6dab1f781f55326543c56dc29ea677759439ddfeba920c83037e6%40%3Cissues.cxf.apache.org%3E https: • CWE-400: Uncontrolled Resource Consumption CWE-770: Allocation of Resources Without Limits or Throttling •
CVE-2018-8039 – apache-cxf: TLS hostname verification does not work correctly with com.sun.net.ssl.*
https://notcve.org/view.php?id=CVE-2018-8039
It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via 'System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");'. When this system property is set, CXF uses some reflection to try to make the HostnameVerifier work with the old com.sun.net.ssl.HostnameVerifier interface. However, the default HostnameVerifier implementation in CXF does not implement the method in this interface, and an exception is thrown. However, in Apache CXF prior to 3.2.5 and 3.1.16 the exception is caught in the reflection code and not properly propagated. What this means is that if you are using the com.sun.net.ssl stack with CXF, an error with TLS hostname verification will not be thrown, leaving a CXF client subject to man-in-the-middle attacks. • https://github.com/tafamace/CVE-2018-8039 http://cxf.apache.org/security-advisories.data/CVE-2018-8039.txt.asc?version=1&modificationDate=1530184663000&api=v2 http://www.securityfocus.com/bid/106357 http://www.securitytracker.com/id/1041199 https://access.redhat.com/errata/RHSA-2018:2276 https://access.redhat.com/errata/RHSA-2018:2277 https://access.redhat.com/errata/RHSA-2018:2279 https://access.redhat.com/errata/RHSA-2018:2423 https://access.redhat.com/errata/RHSA-2018:2424 htt • CWE-248: Uncaught Exception CWE-755: Improper Handling of Exceptional Conditions •
CVE-2017-12624 – cxf: Improper size validation in message attachment header for JAX-WS and JAX-RS services
https://notcve.org/view.php?id=CVE-2017-12624
Apache CXF supports sending and receiving attachments via either the JAX-WS or JAX-RS specifications. It is possible to craft a message attachment header that could lead to a Denial of Service (DoS) attack on a CXF web service provider. Both JAX-WS and JAX-RS services are vulnerable to this attack. From Apache CXF 3.2.1 and 3.1.14, message attachment headers that are greater than 300 characters will be rejected by default. This value is configurable via the property "attachment-max-header-size". • https://github.com/tafamace/CVE-2017-12624 http://cxf.apache.org/security-advisories.data/CVE-2017-12624.txt.asc http://www.securityfocus.com/bid/101859 http://www.securitytracker.com/id/1040486 https://access.redhat.com/errata/RHSA-2018:2423 https://access.redhat.com/errata/RHSA-2018:2424 https://access.redhat.com/errata/RHSA-2018:2425 https://access.redhat.com/errata/RHSA-2018:2428 https://lists.apache.org/thread.html/r36e44ffc1a9b365327df62cdfaabe85b9a5637de102cea07d79b2dbf%40%3Ccommits.cxf.a • CWE-20: Improper Input Validation •