FreeRDP EUVD-2026-115924

Exploitation requires BOTH an on-path man-in-the-middle position on the RDP TCP connection AND possession of a certificate that chains to a CA the FreeRDP client already trusts (a misissuing public CA, or a compromised/rogue/private CA). Given that, two concrete trigger paths exist: Case 2 - a leaf certificate whose Common Name equals the target hostname while its dNSName SAN entries are all non-matching, because FreeRDP consults CN via an unconditional OR even when SAN entries are present (violating RFC 6125 §6.4.4); and Case 3 - an IP-literal target (e.g. 127.0.0.1) matched as a plain string against a CN or DNS-type SAN equal to that IP, because FreeRDP never reads true iPAddress SAN entries. Limiting factors: the attacker cannot bypass a validly-issued, correctly-scoped certificate - the attack depends specifically on trust-chain anomalies (misissuance, rogue/private CA); affected versions are FreeRDP <= 3.32.1, fixed in 3.32.2; AutoDenyCertificate=TRUE is never consulted because hostname_match is wrongly set, so no non-default hardening setting mitigates it. Vendor remediation is to update to 3.32.2 (the advisory's direction is to delegate identity validation to OpenSSL's X509_check_host()/X509_check_ip_asc()).

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N, VC:H/VI:H/VA:N) and the act_now priority label both point to a genuinely serious identity-verification bypass, but the real-world risk is gated by a specific precondition rather than being a trivial remote break. AC:H and AT:P correctly capture that the attacker needs two things that are not under their sole control: an on-path (MITM) position on the RDP TCP connection AND a certificate that chains to a CA the FreeRDP client already trusts (a misissuing public CA, or a compromised/rogue/private CA). It is NOT a no-precondition bypass of a correctly-issued, correctly-scoped certificate. PR:N is accurate - no authentication to FreeRDP itself is required. No EPSS score is provided in the input, and there is no CISA KEV listing, so the exploitation signal rests on the VulnCheck/GHSA PoC and the act_now decision label rather than on observed in-the-wild activity. The most notable risk amplifier is that this is an incomplete-fix case: GHSA-43hh-p3vw-hfx3's metadata claims these cases were fixed in 3.29.0, but the advisory demonstrates Cases 2 and 3 remained byte-identical and unpatched - meaning defenders who believed they were already protected are not. Net: a real priority within environments that use private/enterprise CAs or are exposed to CA-misissuance, given per the act_now label, but lower spray-and-pray risk than the 9.1 headline alone would suggest because of the trusted-CA-certificate precondition.

An attacker on the network path between an RDP client and server (e.g. via ARP/DNS spoofing or a malicious relay) presents a TLS certificate that chains to a CA the FreeRDP client already trusts, crafted so that either its Common Name equals the target hostname while the SAN lists only non-matching names (Case 2), or its CN/DNS-SAN string equals the target IP literal (Case 3). FreeRDP's tls_verify_certificate() wrongly sets hostname_match=TRUE and silently accepts the connection with no prompt, letting the attacker fully intercept the session - screen content, keystrokes, clipboard, and input injection. A detailed PoC/reproduction is documented in the GHSA advisory, though it is a direct-function reproduction harness rather than a published end-to-end network exploit.