CVE-2026-50630

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.

A Content Spoofing vulnerability (CVE-2026-50630) has been identified in the OAuth2 AuthorizationUtils class of the cxf-rt-rs-security-oauth2 module, which allows attackers who can influence the configured realm value to inject Carriage Return (CR) and Line Feed (LF) characters into the WWW-Authenticate header of a 401 response, adding arbitrary HTTP headers or splitting the HTTP response entirely.

Per OWASP: Content spoofing, also referred to as content injection, “arbitrary text injection” or virtual defacement, is an attack targeting a user made possible by an injection vulnerability in a web application. When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.

This issue affects Apache CXF versions before 3.6.12, versions 4.0.0 through 4.1.6, and versions 4.2.0 through 4.2.1, including the End-of-Life 3.5.x line.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-rs-security-oauth2
• Affected versions: <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 all versions before 3.6.12, versions 4.0.0 through 4.1.6, and versions 4.2.0 through 4.2.1 of Apache CXF.

When an OAuth2-protected JAX-RS endpoint rejects a request (for example, because the access token is missing, unknown, expired, or not yet valid), OAuthRequestFilter, AccessTokenValidatorService, and AbstractAccessTokenValidator call AuthorizationUtils.throwAuthorizationFailure(...) with the configured realm. That method builds the WWW-Authenticate challenge by appending the realm directly between double quotes, without removing or encoding control characters:

public static void throwAuthorizationFailure(Set<String> challenges, String realm, Throwable cause) {
    ResponseBuilder rb = JAXRSUtils.toResponseBuilder(401);

    StringBuilder sb = new StringBuilder();
    for (String challenge : challenges) {
        if ("*".equals(challenge)) {
            continue;
        }
        if (sb.length() > 0) {
            sb.append(',');
        }
        sb.append(challenge);
    }
    if (sb.length() > 0) {
        if (realm != null) {
            sb.append(" realm=\"").append(realm).append('"');
        }
        rb.header(HttpHeaders.WWW_AUTHENTICATE, sb.toString());
    }
    if (cause != null) {
        rb.entity(cause.getMessage());
    }
    throw ExceptionUtils.toNotAuthorizedException(cause, rb.build());
}

The realm is normally set through setRealm(String) on the filter or validator. If an application derives that value from anything an attacker can influence (a request attribute, a tenant or host name, or data from an external store), a realm containing \r\n sequences ends the WWW-Authenticate header early. Whatever follows is then treated as additional response headers or as a second, attacker-controlled response body. This enables response splitting, cache poisoning, and spoofed content served under the trusted origin.

This vulnerability was introduced in 2013 with Apache CXF 2.6.9 and 2.7.6.

Mitigation

Only recent versions of Apache CXF are community-supported. The affected 3.5.x line is End-of-Life 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)