CVSS: 9.8EPSS: 1%CPEs: 7EXPL: 0CVE-2019-12419 – cxf: OpenId Connect token service does not properly validate the clientId
https://notcve.org/view.php?id=CVE-2019-12419
Apache CXF before 3.3.4 and 3.2.11 provides all of the components that are required to build a fully fledged OpenId Connect service. There is a vulnerability in the access token services, where it does not validate that the authenticated principal is equal to that of the supplied clientId parameter in the request. If a malicious client was able to somehow steal an authorization code issued to another client, then they could exploit this vulnerability to obtain an access token for the other client. Apache CXF versiones anteriores a la versión 3.3.4 y 3.2.11, provee todos los componentes necesarios para construir un servicio OpenId Connect completamente desarrollado. Existe una vulnerabilidad en los servicios de token de acceso, donde no comprueba que el principal autenticado sea igual al del parámetro clientId proporcionado en la petición. • http://cxf.apache.org/security-advisories.data/CVE-2019-12419.txt.asc https://lists.apache.org/thread.html/r36e44ffc1a9b365327df62cdfaabe85b9a5637de102cea07d79b2dbf%40%3Ccommits.cxf.apache.org%3E https://lists.apache.org/thread.html/r861eb1a9e0250e9150215b17f0263edf62becd5e20fc96251cff59f6%40%3Cdev.cxf.apache.org%3E https://lists.apache.org/thread.html/rc774278135816e7afc943dc9fc78eb0764f2c84a2b96470a0187315c%40%3Ccommits.cxf.apache.org%3E https://lists.apache.org/thread.html/rd49aabd984ed540c8ff7916d4d79405f3fa311d2fdbcf9ed307839a6%40%3Ccommits.cxf.apache.org%3E https: • CWE-287: Improper Authentication CWE-863: Incorrect Authorization •
CVSS: 6.5EPSS: 1%CPEs: 6EXPL: 0CVE-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:&#x • CWE-400: Uncontrolled Resource Consumption CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 8.1EPSS: 0%CPEs: 3EXPL: 1CVE-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 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 1CVE-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 •
CVSS: 7.5EPSS: 0%CPEs: 11EXPL: 0CVE-2017-3156 – cxf: CXF OAuth2 Hawk and JOSE MAC Validation code are vulnerable to timing attacks
https://notcve.org/view.php?id=CVE-2017-3156
The OAuth2 Hawk and JOSE MAC Validation code in Apache CXF prior to 3.0.13 and 3.1.x prior to 3.1.10 is not using a constant time MAC signature comparison algorithm which may be exploited by sophisticated timing attacks. OAuth2 Hawk y JOSE MAC en Apache CXF en versiones anteriores a la 3.0.13 y en versiones 3.1.x anteriores a la 3.1.10 no emplean un algoritmo de comparación de firma MAC de tiempo constante, lo que podría ser explotado por ataques basados en tiempo sofisticados. It was found that Apache CXF OAuth2 Hawk and JOSE MAC Validation code is not using a constant time MAC signature comparison algorithm which may be exploited by some sophisticated timing attacks. It may only affect OAuth2 Hawk or JWT access tokens or JOSE JWS/JWE interceptors which depend on HMAC secret key algorithms. • http://cxf.apache.org/security-advisories.data/CVE-2017-3156.txt.asc http://www.securityfocus.com/bid/96398 https://access.redhat.com/errata/RHSA-2017:1832 https://lists.apache.org/thread.html/r36e44ffc1a9b365327df62cdfaabe85b9a5637de102cea07d79b2dbf%40%3Ccommits.cxf.apache.org%3E https://lists.apache.org/thread.html/rc774278135816e7afc943dc9fc78eb0764f2c84a2b96470a0187315c%40%3Ccommits.cxf.apache.org%3E https://lists.apache.org/thread.html/rd49aabd984ed540c8ff7916d4d79405f3fa311d2fdbcf9ed307839a6%40%3Ccommits.cxf.apache.org%3E https://lists.ap • CWE-385: Covert Timing Channel •