CVE-2026-108039

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.

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.