Search
Total
8 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-40690 | 3 Apache, Debian, Oracle | 18 Cxf, Santuario Xml Security For Java, Tomee and 15 more | 2023-08-18 | 5.0 MEDIUM | 7.5 HIGH |
| All versions of Apache Santuario - XML Security for Java prior to 2.2.3 and 2.1.7 are vulnerable to an issue where the "secureValidation" property is not passed correctly when creating a KeyInfo from a KeyInfoReference element. This allows an attacker to abuse an XPath Transform to extract any local .xml files in a RetrievalMethod element. | |||||
| CVE-2021-22696 | 2 Apache, Oracle | 6 Cxf, Business Intelligence, Communications Diameter Intelligence Hub and 3 more | 2022-05-12 | 5.0 MEDIUM | 7.5 HIGH |
| CXF supports (via JwtRequestCodeFilter) passing OAuth 2 parameters via a JWT token as opposed to query parameters (see: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)). Instead of sending a JWT token as a "request" parameter, the spec also supports specifying a URI from which to retrieve a JWT token from via the "request_uri" parameter. CXF was not validating the "request_uri" parameter (apart from ensuring it uses "https) and was making a REST request to the parameter in the request to retrieve a token. This means that CXF was vulnerable to DDos attacks on the authorization server, as specified in section 10.4.1 of the spec. This issue affects Apache CXF versions prior to 3.4.3; Apache CXF versions prior to 3.3.10. | |||||
| CVE-2021-30468 | 2 Apache, Oracle | 5 Cxf, Tomee, Business Intelligence and 2 more | 2022-04-25 | 5.0 MEDIUM | 7.5 HIGH |
| A vulnerability in the JsonMapObjectReaderWriter of Apache CXF allows an attacker to submit malformed JSON to a web service, which results in the thread getting stuck in an infinite loop, consuming CPU indefinitely. This issue affects Apache CXF versions prior to 3.4.4; Apache CXF versions prior to 3.3.11. | |||||
| CVE-2019-12423 | 2 Apache, Oracle | 8 Cxf, Commerce Guided Search, Communications Diameter Signaling Router and 5 more | 2021-06-17 | 4.3 MEDIUM | 7.5 HIGH |
| Apache CXF ships with a OpenId Connect JWK Keys service, which allows a client to obtain the public keys in JWK format, which can then be used to verify the signature of tokens issued by the service. Typically, the service obtains the public key from a local keystore (JKS/PKCS12) by specifing the path of the keystore and the alias of the keystore entry. This case is not vulnerable. However it is also possible to obtain the keys from a JWK keystore file, by setting the configuration parameter "rs.security.keystore.type" to "jwk". For this case all keys are returned in this file "as is", including all private key and secret key credentials. This is an obvious security risk if the user has configured the signature keystore file with private or secret key credentials. From CXF 3.3.5 and 3.2.12, it is mandatory to specify an alias corresponding to the id of the key in the JWK file, and only this key is returned. In addition, any private key information is omitted by default. "oct" keys, which contain secret keys, are not returned at all. | |||||
| CVE-2017-5656 | 1 Apache | 1 Cxf | 2021-06-16 | 5.0 MEDIUM | 7.5 HIGH |
| Apache CXF's STSClient before 3.1.11 and 3.0.13 uses a flawed way of caching tokens that are associated with delegation tokens, which means that an attacker could craft a token which would return an identifer corresponding to a cached token for another user. | |||||
| CVE-2018-8039 | 2 Apache, Redhat | 2 Cxf, Jboss Enterprise Application Platform | 2021-06-16 | 6.8 MEDIUM | 8.1 HIGH |
| 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. | |||||
| CVE-2017-3156 | 1 Apache | 1 Cxf | 2021-06-16 | 5.0 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2016-8739 | 1 Apache | 1 Cxf | 2021-06-16 | 7.8 HIGH | 7.5 HIGH |
| The JAX-RS module in Apache CXF prior to 3.0.12 and 3.1.x prior to 3.1.9 provides a number of Atom JAX-RS MessageBodyReaders. These readers use Apache Abdera Parser which expands XML entities by default which represents a major XXE risk. | |||||