Apache CXF EUVD-2026-95703

Exploitation requires three conditions: (1) the application uses the Apache CXF Netty-based HTTP client transport (cxf-rt-transports-http-netty-client module) to make outbound TLS calls - this optional transport is the specifically affected component; (2) the attacker holds an active traffic-interception/man-in-the-middle position on the path between the CXF client and the target endpoint; and (3) the attacker possesses any certificate chaining to a CA in the client's configured trust store, such as a free publicly issued cert for an attacker-owned domain. Notably, the flaw is present even with disableCNCheck at its secure default of false, so hardening that setting does NOT mitigate it. Over both HTTP/1.1 and HTTP/2. The primary limiting factor is the MITM-position requirement; no authentication or user interaction is needed, and no special target-side configuration beyond using the affected transport.

This is a genuinely high-severity TLS trust flaw (CWE-297, improper certificate hostname validation) but not an immediate mass-exploitation priority. The vendor CVSS vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:N = 9.1) reflects an unauthenticated network attacker who can fully read and modify traffic including credentials. However, exploitation is gated by a precondition the base score understates: the attacker must already occupy a man-in-the-middle/traffic-interception position between the CXF client and the target service, which in my assessment warrants AC:H (CVSS:3.1) rather than the vendor's AC:L. The exploitation signals are quiet and consistent: EPSS is only 0.11% (1st percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, so there is no public exploit identified at time of analysis. The low EPSS aligns with the MITM requirement - this is a man-in-the-middle enabler rather than a directly weaponizable remote code path, so it favors targeted/positioned attackers over opportunistic internet-wide scanning. Net: patch on a normal cadence and prioritize where CXF clients traverse untrusted networks, but it is not a drop-everything KEV-style emergency.

An Apache CXF application uses the Netty-based HTTP client transport to call a backend SOAP/REST service over TLS. An attacker positioned on the network path (rogue Wi-Fi, ARP/DNS spoofing, compromised upstream hop) presents a valid, publicly issued certificate for a domain they control; because the client validates the chain against its trust store but never checks that the hostname matches, the connection succeeds and the attacker proxies, reads, and alters the traffic including transmitted credentials. No public exploit is identified, and exploitation requires an active interception position rather than a simple remote request.