CVE-2026-61466

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.

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.

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.

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.

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.

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.