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.

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.

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.