Apache CXF’s Netty-based HTTP client transport does not verify that the hostname in a server’s TLS certificate matches the target host, even when the disableCNCheck flag remains at its default false value. This omission lets an attacker who can intercept or observe the client‑server communication present any certificate that the client trusts, regardless of the domain for which it was issued. The attacker can then impersonate the intended service, read the encrypted payload, or modify messages—including credentials—during transit.

Apache Software Foundation’s Apache CXF, specifically its Netty HTTP client transport (cxf-rt-transports-http-netty-client). All releases older than 4.2.4, 4.1.9, or 3.6.13 are vulnerable to this hostname‑verification deficiency.

EPSS information is not available and the vulnerability has not been cataloged in CISA KEV. The attack requires the attacker to control or observe the network path between client and server, which is an inference from the described interception scenario. If achieved, the attacker gains the ability to substitute any trusted certificate issued for a different domain and thus performs a man‑in‑the‑middle attack, fully compromising confidentiality and integrity of the TLS protected traffic. The CVSS score for this vulnerability is not available.