A flaw was found in cxf in versions prior to 3.2.11 and 3.3.4. The access token services do not properly validate that an authenticated principal is equal to that of the supplied clientId parameter allowing a malicious client to use an authorization code that has been issued to a different client as their own. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A flaw was found in the way Apache CXF handle exceptions when CXF is configured to use the com.sun.net.ssl implementation via System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol") function. 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 therefore an exception is thrown. The exception is caught in the reflection code but not properly propagated which leaves CXF client subject to man-in-the-middle attacks.
Upstream Patch: https://github.com/apache/cxf/commit/fae6fabf9bd7647f5e9cb68897a7d7
A flaw was found in Apache CXF prior to 3.2.1 and 3.1.14. 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.
Upstream patch:
https://github.com/apache/cxf/commit/8bd915bfd7735c248ad660059c6b6ad26cdbcdf6
References:
http://cxf.apache.org/security-advisories.data/CVE-2017-12624.txt.asc
Apache CXF is vulnerable to cross-site scripting, caused by improper validation of user-supplied input by the services listing page. A remote attacker could exploit this vulnerability using a specially-crafted URL to execute script in a victim's Web browser within the security context of the hosting Web site, once the URL is clicked. An attacker could use this vulnerability to steal the victim's cookie-based authentication credentials.