CVE-2026-50623

Overview

Apache CXF is an open-source services framework, maintained by the Apache Software Foundation, for building and consuming web services in Java. It implements the JAX-WS and JAX-RS APIs and supports SOAP, the WS-* standards, RESTful HTTP, and OAuth 2.0 over transports such as HTTP and JMS. Its modules are published as Maven artifacts under org.apache.cxf.

An Authorization Bypass vulnerability (CVE-2026-50623) has been identified in the OAuth2 TokenIntrospectionService of the cxf-rt-rs-security-oauth2 module, which allows unauthenticated network attackers who hold or guess a token value to call the OAuth2 token introspection endpoint and learn whether that token is active, along with its client ID, scopes, subject, audience, and expiry.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects versions 3.1.5 through 3.6.11, 4.0.0 through 4.1.6, and 4.2.0 through 4.2.1 of Apache CXF.

Details

Product: Apache CXF
Affected packages: org.apache.cxf:cxf-rt-rs-security-oauth2
Affected versions: >=3.1.5 <3.6.12, >=4.0.0 <4.1.7, >=4.2.0 <4.2.2
GitHub repository: https://github.com/apache/cxf
Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-rs-security-oauth2
Package manager: Maven
Fixed in:

• OSS Apache CXF 3.6.12, 4.1.7, 4.2.2
• NES for Apache CXF v3.5.13, v3.4.12

Vulnerability Info

This Medium-severity vulnerability is found in the cxf-rt-rs-security-oauth2 package in versions 3.1.5 through 3.6.11, 4.0.0 through 4.1.6, and 4.2.0 through 4.2.1 of Apache CXF.

TokenIntrospectionService exposes the RFC 7662 token introspection endpoint (the introspect JAX-RS resource). Every request to getTokenIntrospection() first calls checkSecurityContext(), which is meant to reject callers that have no authenticated principal (blockUnauthorizedRequests, enabled by default) and, optionally, callers that are not using TLS (blockUnsecureRequests). Both checks log a warning and build a NotAuthorizedException, but the exception is never thrown:

@POST
@Produces({MediaType.APPLICATION_JSON })
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public TokenIntrospection getTokenIntrospection(@Encoded MultivaluedMap<String, String> params) {
    checkSecurityContext();
    String tokenId = params.getFirst(OAuthConstants.TOKEN_ID);
    ...
    ServerAccessToken at = dataProvider.getAccessToken(tokenId);
    ...
}

private void checkSecurityContext() {
    SecurityContext sc = mc.getSecurityContext();
    if (!sc.isSecure() && blockUnsecureRequests) {
        LOG.warning("Unsecure HTTP, Transport Layer Security is recommended");
        ExceptionUtils.toNotAuthorizedException(null,  null);
    }
    if (sc.getUserPrincipal() == null && blockUnauthorizedRequests) {
        LOG.warning("Authenticated Principal is not available");
        ExceptionUtils.toNotAuthorizedException(null, null);
    }
}

Because checkSecurityContext() always returns normally, the method goes on to look up the submitted token parameter and return its introspection data to any caller. When the introspection endpoint is deployed without separate transport-level or container authentication in front of it, an unauthenticated attacker who holds or guesses a token value can confirm that the token is active and read its metadata (client ID, scope, username, subject, audience, issuer, issue and expiry times, and, if reportExtraTokenProperties is enabled, extra token properties). The built-in principal and TLS checks are the service's own safeguard for deployments that forgot to enable authentication, and that safeguard is ineffective.

This vulnerability was introduced in 2016 with Apache CXF 3.1.5.

Mitigation

Only recent versions of Apache CXF are community-supported. The 3.5.x line was already End-of-Life when this CVE was published and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Apache CXF release line (3.6.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

Guanping Zhang (finder)