A vulnerability in Apache CXF's JwsJsonContainerRequestFilter can be exploited to cause CXF to process metadata that was not authenticated by the accepted signature. This can bypass the application's assumption

that accepted Content-Type or protected HTTP-header metadata came from a verified signature entry, and may steer downstream JAX-RS entity parsing or signed-header consistency checks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fix this issue.

A CRLF injection vulnerability exists in the OAuth2 AuthorizationUtils class. When constructing the WWW-Authenticate response header, the 'realm' parameter is concatenated without sanitizing Carriage Return (CR) and Line Feed (LF) characters. If an attacker can control the realm value, they can inject arbitrary HTTP headers or split the HTTP response entirely. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.

An authentication bypass vulnerability exists in the OAuth2 TokenIntrospectionService in Apache CXF. Due to a missing 'throw' keyword in the security context check, the introspection endpoint (/services/oauth2/introspect) can be accessed by any unauthenticated network attacker. However note that this is a safeguard only in the case that someone forgot to enable authentication on the service. Users are recommended to upgrade to version 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.

The 'clientId' parameter from incoming HTTP requests is directly concatenated into OAuth2 server log warning messages without sanitizing control characters. This allows an attacker to inject arbitrary content, including fake log entries, into the server's log files. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.

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

In versions of Apache CXF before 3.6.4 and 4.0.5 (3.5.x and lower versions are not impacted), a CXF HTTP client conduit may prevent HTTPClient instances from being garbage collected and it is possible that memory consumption will continue to increase, eventually causing the application to run out of memory

An improper input validation of the p2c parameter in the Apache CXF JOSE code before 4.0.5, 3.6.4 and 3.5.9 allows an attacker to perform a denial of service attack by specifying a large value for this parameter in a token.

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 supports the ability to use XML Signature and encryption to secure JAX-RS services. Two different implementations are available, a DOM based approach that works on a model of the message in memory before applying security, and a streaming based implementation that is a useful alternative for larger messages.

There is a bug in validating messages for JAX-RS clients using the streaming approach, where it will not enforce that the message is signed and/or encrypted. An exception is thrown in these cases but not properly propagated to the client code. The bug does not apply for the DOM clients and it does not apply for the streaming server side case.

External References:

http://cxf.apache.org/security-advisories.data/CVE-2017-5653.txt.asc

Upstream patch:

https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=fade9b81dabe27f864ca38e7b40f28fb44d6f165

Apache CXF HTTP transport module uses FormattedServiceListWriter to provide an HTML page which lists the names and absolute URL addresses of the available service endpoints. The module calculates the base URL using the current HttpServletRequest. The calculated base URL is used by FormattedServiceListWriter to build the service endpoint absolute URLs. If the unexpected matrix parameters have been injected into the request URL then these matrix parameters will find their way back to the client in the services list page which represents an XSS risk to the client.

External References:

http://cxf.apache.org/security-advisories.data/CVE-2016-6812.txt.asc?version=1&modificationDate=1482164360602&api=v2

Insecure XML parser configuration in Apache CXF's WS-Transfer module may allow attackers to perform XXE attacks. Users are recommended to upgrade to versions 4.2.1, 4.1.6 or 3.6.11, which fix this issue.

Apache CXF has the ability to integrate with JMX by registering an InstrumentationManager extension with the CXF bus. If the createMBServerConnectorFactory property of the default InstrumentationManagerImpl is not disabled, then it is vulnerable to a man-in-the-middle (MITM) style attack. An attacker on the same host can connect to the registry and rebind the entry to another server, thus acting as a proxy to the original. They are then able to gain access to all of the information that is sent and received over JMX.

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 the styleSheetPath in 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.

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.

Apache CXF before 2.6.14 and 2.7.x before 2.7.11 allows remote attackers to cause a denial of service (memory consumption) via a large request with the Content-Type set to text/html to a SOAP endpoint, which triggers an error.

Apache CXF before 2.6.14 and 2.7.x before 2.7.11 allows remote attackers to cause a denial of service (/tmp disk consumption) via a large invalid SOAP message.

A flaw was found in JBoss web services where the services used a weak symmetric encryption protocol, PKCS#1 v1.5. An attacker could use this weakness in chosen-ciphertext attacks to recover the symmetric key and conduct further attacks.

DISPUTED The wsdlfirsthttps sample code in distribution/src/main/release/samples/wsdlfirsthttps/src/main/ in Apache CXF before 2.7.0 does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate. NOTE: The vendor states that the sample had specifically used a flag to bypass the DN check.

Apache CXF 2.5.x before 2.5.10, 2.6.x before CXF 2.6.7, and 2.7.x before CXF 2.7.4 does not verify that a specified cryptographic algorithm is allowed by the WS-SecurityPolicy AlgorithmSuite definition before decrypting, which allows remote attackers to force CXF to use weaker cryptographic algorithms than intended and makes it easier to decrypt communications, aka "XML Encryption backwards compatibility attack."

The URIMappingInterceptor in Apache CXF before 2.5.8, 2.6.x before 2.6.5, and 2.7.x before 2.7.2, when using the WSS4JInInterceptor, bypasses WS-Security processing, which allows remote attackers to obtain access to SOAP services via an HTTP GET request.

Apache CXF before 2.4.9, 2.5.x before 2.5.5, and 2.6.x before 2.6.2 allows remote attackers to execute unintended web-service operations by sending a header with a SOAP Action String that is inconsistent with the message body.

Apache CXF 2.4.5 through 2.4.7, 2.5.1 through 2.5.3, and 2.6.x before 2.6.1, does not properly enforce child policies of a WS-SecurityPolicy 1.1 SupportingToken policy on the client side, which allows remote attackers to bypass the (1) AlgorithmSuite, (2) SignedParts, (3) SignedElements, (4) EncryptedParts, and (5) EncryptedElements policies.

Multiple denial of service flaws were found in the way StAX parser implementation of Apache CXF, an open-source web services framework, performed processing of certain XML files. If a web service application utilized the services of the StAX parser, a remote attacker could provide a specially-crafted XML file that, when processed by the application would lead to excessive system resources (CPU cycles, memory) consumption by that application.

References: [1] http://jira.codehaus.org/browse/WSTX-287 [2] http://jira.codehaus.org/browse/WSTX-285

Apache CXF before 2.5.9, 2.6.x before 2.6.6, and 2.7.x before 2.7.3, when the plaintext UsernameToken WS-SecurityPolicy is enabled, allows remote attackers to bypass authentication via a security header of a SOAP request containing a UsernameToken element that lacks a password child element.

Apache WSS4J as used by Apache CXF with the TransportBinding does not, by default, properly enforce all security requirements associcated with SAML SubjectConfirmation methods. Web service endpoints, secured by WSS4j, that rely on SAML for authentication are considered vulnerable to types of spoofing attacks.

Upstream Issues:

https://issues.apache.org/jira/browse/WSS-510 https://issues.apache.org/jira/browse/WSS-511 https://issues.apache.org/jira/browse/WSS-511

Upstream Commits:

http://svn.apache.org/viewvc?view=revision&revision=1624308 http://svn.apache.org/viewvc?view=revision&revision=1624287 http://svn.apache.org/viewvc?view=revision&revision=1624262

References:

http://cxf.apache.org/security-advisories.data/CVE-2014-3623.txt.asc

The SamlHeaderInHandler in Apache CXF before 2.6.11, 2.7.x before 2.7.8, and 3.0.x before 3.0.1 allows remote attackers to cause a denial of service (infinite loop) via a crafted SAML token in the authorization header of a request to a JAX-RS service.

The SecurityTokenService (STS) in Apache CXF before 2.6.12 and 2.7.x before 2.7.9 does not properly validate SAML tokens when caching is enabled, which allows remote attackers to gain access via an invalid SAML token.

The SymmetricBinding in Apache CXF before 2.6.13 and 2.7.x before 2.7.10, when EncryptBeforeSigning is enabled and the UsernameToken policy is set to an EncryptedSupportingToken, transmits the UsernameToken in cleartext, which allows remote attackers to obtain sensitive information by sniffing the network.

The SAML Web SSO module in Apache CXF before 2.7.18, 3.0.x before 3.0.7, and 3.1.x before 3.1.3 allows remote authenticated users to bypass authentication via a crafted SAML response with a valid signed assertion, related to a "wrapping attack."

Apache CXF is vulnerable to SOAPAction spoofing attacks under certain conditions. If web services are exposed via Apache CXF that use a unique SOAPAction for each service operation, then a remote attacker could perform SOAPAction spoofing to call a forbidden operation if it accepts the same parameters as an allowed operation. WS-Policy validation is performed against the operation being invoked, and an attack must pass validation to be successful.