Apache Thrift EUVD-2026-91418

Exploitation requires ALL of: (1) an attacker positioned on the network path (man-in-the-middle) between a Thrift client and server; (2) the client using the C++ TSSLSocketFactory default access manager or the D accessManager property for SSL client sockets; (3) the attacker possessing a certificate that chains to a certificate authority already in the client's trust store; and (4) that certificate carrying a Common Name equal to the connected hostname while all of its subjectAltName dNSName entries are present but non-matching (the non-matching SANs yield 'skip' and fall through to the CN). Limiting factors: because public CAs stopped issuing on Common Name alone years ago, this is practically confined to deployments using private/enterprise PKI; it only affects the C++ (0.7.0-0.24.0) and D (0.9.0-0.24.0) libraries, not other language bindings; and the required MITM position plus trusted CN-matching certificate make opportunistic mass exploitation impractical.

This is a genuine but moderate-priority flaw whose signals are internally consistent rather than conflicting. The vendor-supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N, base 6.9) correctly captures a network-exploitable certificate-validation bypass (CWE-295) that needs no privileges or user interaction but carries both high attack complexity and a present attack requirement (AT:P) - reflecting that the attacker must occupy a privileged man-in-the-middle position AND possess a certificate chaining to a CA in the client's trust store with a CN matching the target host. The CVSS exploit-maturity field is E:U (unreported), there is no CISA KEV listing, no EPSS value was provided in the intelligence, and no POC was referenced, so exploitation status is: no public exploit identified at time of analysis. The high AT/AC requirements plus the vendor's own observation that public CAs abandoned CN-only issuance years ago mean real-world risk is largely confined to deployments using private or enterprise PKI. Net: a legitimate confidentiality/integrity bug worth patching on a normal cadence, not an emergency; it is a high-CVSS-relative-to-exploitability issue gated by stringent preconditions rather than a mass-exploitation threat. Missing data to note explicitly: no EPSS score was supplied and POC availability is unstated, so likelihood scoring beyond the qualitative CVSS signals cannot be confirmed.

An attacker already able to intercept traffic on the network path between a Thrift C++ or D client and its server (e.g., a compromised router or ARP/DNS spoofing within an enterprise segment) presents a server certificate whose subjectAltName dNSName entries are all non-matching but whose Common Name equals the hostname the client dialed, and which chains to a CA trusted by the client. The default access manager accepts it, letting the attacker impersonate the legitimate server and silently intercept or modify RPC calls. No public exploit code is identified at time of analysis, and exploitation hinges on the attacker holding a trusted CN-matching certificate.