Apache CXF vulnerabilities

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.

In Apache CXF's DefaultEncryptingCodeDataProvider, an authorization code can be redeemed an unlimited number of times due to a flaw in the removeCodeGrant implementation. This violates the RFC requirement that the authorization code must not be used more than once. Users are advised to upgrade to versions 4.2.3, 4.1.8, or 3.6.12.

Apache CXF's OIDC relying-party token validation could accept self-issued ID tokens without enforcing required claim checks (issuer/subject/audience/time and sub_jwk binding), enabling authentication bypass with crafted tokens. Note that self-issued ID tokens are not accepted by default. Users are advised to upgrade to versions 4.2.3, 4.1.8, or 3.6.12.

Apache CXF's JwtRequestCodeFilter copies all claims from a signed request JWT into the authorization parameter map without excluding security-sensitive parameters. A client that can produce a validly-signed request JWT can substitute code_challenge, code_challenge_method, nonce, and state values, undermining PKCE integrity and OpenID Connect replay protection. Users are advised to upgrade to versions 4.2.3, 4.1.8, or 3.6.12.

In Apache CXF's OAuth2 Dynamic Client Registration endpoint, the authorization server accepts and stores the `scope` value supplied in the client registration request verbatim, without validating it against an AS-defined allowlist. This could lead to a client self-assigning privileged scopes at registration time. Users are advised to upgrade to versions 4.2.3, 4.1.8, or 3.6.12.

Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed.

A logic error in OAuthRequestFilter rejects legitimate requests from the bound IP address while blindly allowing requests from any other IP, creating an inverse security check.

The JwtAccessTokenValidator class in Apache CXF fails to validate the 'aud' claims of JWT access tokens, allowing token replay across different resource servers and enabling Token Confusion/Routing attacks.

Apache CXF's EndpointReferenceUtils and W3CMultiSchemaFactory construct a SAXParserFactory without proper JAXP hardening, enabling out-of-band external entity resolution.

An LDAP injection vulnerability in the LDAP Certificate repository of the XKMS server in Apache CXF. It allows an attacker to retrieve arbitrary certificates from the repository.

The WS-SP UsernameToken policy in Apache CXF versions 2.4.5 and 2.5.1 allows remote attackers to bypass authentication by sending an empty UsernameToken as part of a SOAP request.

In Apache CXF's DefaultEncryptingOAuthDataProvider, revoked access tokens still decrypt successfully, and TokenIntrospectionService reports active:true. The same applies to refresh tokens. This violates the RFC stipulations that 'The authorization server MUST invalidate the token.' and 'introspection of a revoked token MUST return {"active":false}'. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

A race condition in JCacheCodeDataProvider allows an attacker to redeem a single authorization code multiple times via concurrent requests, resulting in the issuance of multiple distinct, valid access tokens. Users are recommended to upgrade to versions 4.2.3, 4.1.8 or 3.6.12, which fix this issue.

Apache CXF reads a top-level WSDL through its hardened StaxUtils path, which disables XML DTDs and external entities. However, any <wsdl:import> or <xsd:import> referenced from that top-level WSDL is handed off to WSDL4J, which does not disable DOCTYPE declarations or external entities. As a result, the protections applied to the top-level document do not extend to imported documents, leaving imported WSDL/XSD content vulnerable to XML External Entity (XXE) attacks.

An incomplete fix for CVE-2026-50645 means that it is still possible to perform a denial of service attack on Apache CXF by sending a message with many attachment headers. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Apache CXF allows to set a limit on the number of form parameters in a JAX-RS message via the "maxFormParameterCount" configuration option. However, no default limit is set which may lead to denial of service attacks when processing requests with very large numbers of form parameters. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue by using a default limit of 500 parameters.

The OpenID Connect Core 1.0 specification mandates that the RP MUST validate the `c_hash` parameter when operating in the Hybrid Flow. If an Apache CXF RP is integrated with a non-compliant or misconfigured Identity Provider (IdP) that omits the `c_hash`, the RP becomes vulnerable to Authorization Code Substitution/Injection attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Apache CXF allows to control the maximum attachment size via the "attachment-max-size". Prior to Apache CXF 4.2.3 and 4.1.8 and 3.6.12, there was no default placed on this size, meaning that a denial of service attack is possible if the user doesn't explicitly set the limit. Users should update to Apache CXF 4.2.3 or 4.1.8 or 3.6.12 which fixes this problem by imposing a default attachment size limit of 50mb.

Lack of restriction on the number of attachment headers in Apache CXF during message deserialization can lead to uncontrolled resource consumption or a denial of service attack. Users are recommended to upgrade to versions 4.2.2, 4.1.7, or 3.6.12, which impose a default maximum of 500 attachments per message.

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 affect downstream JAX-RS entity parsing or signed-header consistency checks. Upgrade to versions 4.2.2, 4.1.7, or 3.6.12.

A JNDI Injection vulnerability in Apache CXF's JCA integration module can allow code execution if an attacker can manipulate the JCA deployment descriptor or runtime activation parameters.

A further incomplete fix for CVE-2026-44417 (Untrusted JMS configuration can lead to RCE) in Apache CXF has been identified, which can still allow code execution if untrusted users are allowed to configure JMS.

A race condition in AbstractOAuthDataProvider allows concurrent requests using the same refresh token to bypass single-use semantics and generate multiple valid access tokens when 'recycleRefreshTokens' is set to false. Users are recommended to upgrade to versions 4.2.2, 4.1.7, or 3.6.12.

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 can be accessed by any unauthenticated network attacker. Note this is a safeguard only if someone forgot to enable authentication. Upgrade to versions 4.2.2, 4.1.7, or 3.6.12.

XXE vulnerability in the WS-Transfer module in Apache CXF due to insecure XML parser configuration. An attacker can inject malicious XML entities.

The fix for CVE-2025-48913 in Apache CXF was incomplete, meaning another code path might allow code execution if untrusted users can configure JMS for Apache CXF. Users are recommended to upgrade to versions 4.2.1, 4.1.6, or 3.6.11.