CVE-2026-107938

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 improper certificate validation vulnerability (CVE-2026-107938) has been identified in the Netty-based HTTP client transport of Apache CXF, which allows attackers who can intercept network traffic to impersonate the target service by presenting any certificate the client trusts, even one issued for a different hostname. The attacker can then read or modify the exchanged messages, including credentials.

MITRE's CWE-297 describes Improper Validation of Certificate with Host Mismatch as follows: The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host. Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the product is interacting with.

This issue affects multiple versions of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-transports-http-netty-client
• Affected versions: <3.6.13, >=4.0.0 <4.1.9, >=4.2.0 <4.2.4
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-transports-http-netty-client
• Package manager: Maven
• Fixed in:
  
  • OSS Apache CXF 3.6.13, 4.1.9, 4.2.4
  • NES for Apache CXF v3.4.13, v3.5.14

Vulnerability Info

This High-severity vulnerability is found in the org.apache.cxf:cxf-rt-transports-http-netty-client package in multiple versions of Apache CXF. When a client endpoint uses the Netty HTTP transport over TLS, NettyHttpClientPipelineFactory.configureClientSSLOnDemand creates the client SSLEngine without telling it which host it is connecting to and without any hostname-verifying trust manager. On the HTTP/2 path the engine comes from a Netty SslContext built over the plain configured trust managers, and on the HTTP/1.1 path it comes from SSLUtils.createClientSSLEngine:

if (enableHttp2) {
    final SSLContextInitParameters initParams = SSLUtils.getSSLContextInitParameters(tlsClientParameters);
    sslEngine = SslContextBuilder
        .forClient()
        // key and trust managers taken from initParams
        ...
        .build()
        .newEngine(channel.alloc());
} else {
    sslEngine = SSLUtils.createClientSSLEngine(tlsClientParameters);
}

public static SSLEngine createClientSSLEngine(TLSClientParameters parameters) throws Exception {
    SSLContext sslContext = getSSLContext(parameters);
    SSLEngine clientEngine = sslContext.createSSLEngine();
    clientEngine.setUseClientMode(true);
    return clientEngine;
}

In both cases the TLS handshake only checks that the server's certificate chains to a certificate in the configured trust store. Nothing compares the certificate's subject or subject alternative names against the host in the endpoint URL, so the configured HostnameVerifier is never applied, even when disableCNCheck is left at its default value of false. The only hostname check in NettyHttpConduit runs when a trust decider is configured, so it does not protect the default configuration. A network attacker who can intercept the connection can therefore present any certificate the client trusts, such as a publicly issued certificate for a domain they control, and the client will complete the handshake and send its request, including any credentials, to the attacker.

Mitigation

Only recent versions of Apache CXF are community-supported. Older lines are 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.