Apache bRPC EUVD-2026-107178

Exploitation requires ALL of the following: (1) an application using a bRPC client Channel with client-side TLS peer verification (VERIFY_PEER) enabled; (2) the connection traverses an untrusted network where an attacker can redirect or intercept it (active MITM); and (3) the client trusts a CA that can issue certificates for identities other than the intended endpoint, and the attacker holds such a certificate. Limiting factors that reduce realistic risk: the attacker must already achieve an on-path/MITM position, must possess a valid CA-issued certificate for some other name, and only affected deployments are those NOT using HTTPS Channels (which already verify against the URL host). Deployments trusting only a tightly scoped private CA are far less exposed.

No CVSS score or vector was provided by NVD/vendor, so attack-vector and privilege signals must be inferred from the description. EPSS, KEV, and POC data are all absent from the input: there is no CISA KEV listing and no public exploit identified - only a vendor fix PR (apache/brpc#3408), which is remediation code, not weaponized exploit code. The flaw (CWE-297, improper certificate-to-host binding) is network-reachable but is NOT a trivial remote code bug: successful exploitation requires an active man-in-the-middle position AND possession of a valid certificate issued by a CA the client already trusts for a *different* name. This elevates real-world attack complexity substantially. My independent assessment is AV:N/AC:H/PR:N/UI:N, yielding a High (~7.4) base score driven by confidentiality and integrity impact. This is a genuine transport-security weakness worth patching, but it is a conditional, position-dependent MITM issue rather than a mass-exploitable, internet-wide critical - treat as medium-priority unless bRPC clients traverse untrusted networks trusting broad/public CAs. Note: with no EPSS and no KEV, there is no evidence of active or widespread exploitation at time of analysis.

A bRPC client with TLS peer verification enabled connects across an untrusted network to a backend service, trusting a CA capable of issuing certificates for many identities. An attacker positioned to redirect or intercept the connection presents a valid certificate that the CA issued for a different name; because bRPC validates the chain but never checks the certificate's SAN/CN against the intended endpoint, the handshake succeeds and the attacker transparently impersonates the server, reading and modifying RPC traffic. No public exploit code was identified; only the upstream fix PR exists.