CVE-2026-67294

FreeRDP before 3.29.0 fails to correctly enforce the Extended Key Usage (EKU) purpose of a server certificate during client-side TLS authentication of RDP servers: in x509_utils_verify(), when SSL-server purpose (X509_PURPOSE_SSL_SERVER) validation fails, the code falls back to client-purpose and any-purpose checks and accepts the certificate anyway. An attacker who can intercept the connection (network man-in-the-middle) can present a trusted, hostname-matching certificate that is valid only for clientAuth, and the client will accept it as a legitimate RDP server certificate. This lets the attacker impersonate the RDP server, terminate the TLS session, and capture credentials and session content (the CVSS 4.0 score of 9.3 reflects high confidentiality, integrity, and availability impact). Any deployment of FreeRDP-based RDP clients is affected, most acutely in environments that rely on EKU separation between client and server certificates, including downstream products that embed the FreeRDP library. No in-the-wild exploitation is currently known; EPSS is 0.3% and a public advisory/reference (GHSA-89c6-jjrw-96h4) exists, but the flaw is not in CISA KEV.

What to do: Upgrade FreeRDP to 3.29.0 or later, and apply vendor updates for downstream products that embed FreeRDP (such as Remmina, Apache Guacamole, and thin-client software) as patched builds become available. Until patched, restrict which CAs may issue clientAuth-only certificates trusted by endpoints, require RDP connections over trusted networks or VPNs to reduce man-in-the-middle opportunities, and do not relax or disable client-side certificate verification. Organizations relying on EKU separation between client and server certificates should review their CA issuance policies for certificates matching RDP hostnames.