Apache CXF vulnerabilities

In Apache CXF, STSTokenValidator stored the SAML assertion signature verification result in an object shared across all requests, allowing one request to read another's result. A remote, unauthenticated attacker could send a forged assertion signed with an untrusted certificate that was accepted as trusted without reaching the STS. Only services using STSTokenValidator without alwaysValidateToSts set are affected.

Apache CXF's STSTokenValidator and Security Token Service (STS) cached validated security tokens using a non-cryptographic 32-bit hash (Java Arrays.hashCode/hashCode()) and treated a cache hit as proof of validation. An attacker could craft a token (e.g., UsernameToken or self-signed SAML Assertion) whose hash collides with a cached entry, allowing acceptance without password validation, signature trust verification, or STS call. This could let the attacker authenticate as another user and obtain STS-signed tokens for that identity.

Apache CXF's FIQL query parser has a vulnerability in how it searches for operators in query expressions. The search pattern can get stuck trying many combinations when it encounters a long string without an operator, causing excessive CPU consumption. An attacker can send a crafted query to exhaust server CPU resources, potentially slowing down or stopping other requests. The fix limits FIQL expressions to 4 KiB by default.

Apache CXF's OIDC relying-party component could redirect users to an attacker-controlled URL after successful authentication. The issue occurs because attacker-controlled state parameters are preserved and later used as redirect targets without validating that the final decoded URI belongs to the RP's origin. Both directly encoded and double-encoded external URLs can trigger the issue.

CompressionUtils.inflate() decompressed attacker-controlled DEFLATE data with no output-size cap. A small (~KB) crafted payload could expand to gigabytes on the heap. This was reachable via JWE decryption when zip=DEF (e.g., JoseSessionTokenProvider with RSA-OAEP) and via SAML redirect/POST binding token inflation — in both cases decompression happens before or independent of trust validation. The fix adds a configurable maximum inflated-size cap (default 10 MiB).

Improper enforcement of single-use authorization code semantics in the JPA OAuth2 authorization code grant provider in Apache CXF allows a remote attacker to obtain multiple valid access tokens from a single authorization code via concurrent token exchange requests that race the non-atomic find-then-delete operation against a shared relational database under READ_COMMITTED isolation.

The max_age authentication-freshness check in OidcClientCodeRequestFilter was inoperative due to a milliseconds/seconds unit mismatch and an inverted comparison polarity. Any relying party using setMaxAgeOffset to enforce re-authentication would silently accept sessions of any age, bypassing step-up authentication policies.

By default, StaxUtils placed no limit on the total number of elements or characters in an XML document. A very large request could use a lot of memory and CPU during parsing, especially where CXF builds a DOM from the input (e.g., SAAJ or WS-Security), and could cause a denial of service when no request size limit was configured. Both limits now have defaults: maximum element count is 100 × maxChildElements (5,000,000 by default), and maximum document size is 256M characters.

In Apache CXF, the Netty-based HTTP client transport (cxf-rt-transports-http-netty-client) did not verify that the hostname in the server's TLS certificate matched the host being called. This applied over both HTTP/1.1 and HTTP/2, even when disableCNCheck was left at its default value of false. The certificate chain was validated against the configured trust store, but the endpoint's identity was not. A network attacker able to intercept traffic could present any certificate trusted by the client, such as a publicly issued certificate for a domain they control, and impersonate the target service. They could then read or modify the exchanged messages, including credentials.

The multipart/MTOM attachment header parser in Apache CXF did not fully enforce the configured size and count limits. The size limit applied only to individual lines, not to values built from continuation lines or combined repeated headers. A remote, unauthenticated attacker could send a request with very large headers, causing unbounded memory allocation and denial of service.

The JAX-RS XML Security module in Apache CXF did not properly verify XML signatures. The XML signature interceptors did not ensure that the XML passed to the application was covered by the signature. An attacker with a document signed by a trusted key could wrap it in unsigned content, which the application would treat as signed.

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.

This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. It is a duplicate of CVE-2026-1829.

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.