CVE-2026-107938: Apache CXF: The Netty HTTP client transport does not perform TLS hostname verification.
Apache CXF Netty HTTP client skipped TLS hostname verification, enabling potential man-in-the-middle attacks.
55
Vulnerability6 · 4 reads
CVE-2026-107938
Missing TLS hostname check in Apache CXF Netty HTTP client
- CVSS 3.1
- 9.1 critical
- EPSS
- —
- Published
- ·
- Modified
AI analysisSummaries by Vani AI
Apache CXF’s Netty-based HTTP client transport (cxf-rt-transports-http-netty-client) validates the server certificate chain against the configured trust store but does not check that the certificate hostname matches the host being called. The gap applies to both HTTP/1.1 and HTTP/2 even when disableCNCheck remains at its default of false. A network attacker who can intercept traffic can present any certificate the client already trusts, including a publicly issued certificate for a domain they control, and impersonate the intended service. That lets the attacker read or modify the messages in transit, including credentials. Users of affected CXF releases should move to 4.2.4, 4.1.9, or 3.6.13; there is no known public proof of concept and the issue is not listed in CISA KEV.
What to do: Upgrade the Apache CXF Netty HTTP client transport to 4.2.4, 4.1.9, or 3.6.13. Confirm whether cxf-rt-transports-http-netty-client is on the classpath; leaving disableCNCheck at its default of false does not enable hostname checks in affected builds. Until upgraded, treat TLS sessions from this client as vulnerable to interception by anyone who can present a certificate already trusted by the client.
| Product | Affected |
|---|---|
| Apache Software Foundation Apache CXF (cxf-rt-transports-http-netty-client) | Netty HTTP client transport builds before the fixes in 4.2.4, 4.1.9, and 3.6.13 |
Estimated exposure
No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description · NVD
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. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.