CVE-2026-121392 in FreeRDP
Summary
by MITRE • 11/03/2026
FreeRDP before 3.32.2 contains an improper certificate validation vulnerability in tls_verify_certificate() that accepts Common Name fallback despite non-matching SAN entries and matches IP literals against DNS strings. Man-in-the-middle attackers holding a certificate from a client-trusted CA can bypass server identity checks to intercept RDP sessions, including keystrokes, clipboard, and screen content.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in FreeRDP versions prior to 3.32.2 represents a critical failure in the Transport Layer Security (TLS) certificate validation process, specifically within the tls_verify_certificate function. This flaw stems from an improper handling of X.509 certificate fields during the identity verification phase of the TLS handshake. In modern secure communications, server identity is primarily established through Subject Alternative Name (SAN) entries that match the hostname or IP address used by the client to connect. However, this implementation retains legacy behavior where it falls back to validating against the Common Name field if SAN validation fails or does not strictly enforce precedence rules. Furthermore, the code incorrectly allows matching of literal IP addresses against DNS name strings in certificates, a practice that violates RFC 2818 and subsequent best practices which mandate strict equality checks between the connection target and the certificate identities. This architectural oversight creates a significant gap in authentication integrity, allowing attackers to exploit trust relationships established by Certificate Authorities without possessing valid credentials for the specific server being accessed.
From an operational perspective, this vulnerability enables sophisticated man-in-the-middle attacks against Remote Desktop Protocol sessions. An adversary who controls a network position between the client and the target RDP server can intercept traffic if they possess a certificate issued by any CA trusted by the FreeRDP client configuration. Because the validation logic accepts certificates where the Common Name matches or incorrectly maps IP literals to DNS strings, an attacker does not need a certificate specifically issued for the targeted host; they only need one that is broadly trusted and contains compatible identifiers. Once the TLS tunnel is established under this false pretense, all data transmitted through the session becomes visible to the attacker. This includes sensitive keystrokes entered by users, clipboard contents containing copied text or files, and real-time screen captures of the remote desktop environment. The impact extends beyond simple eavesdropping; it facilitates credential harvesting, intellectual property theft, and potential lateral movement within an organization if compromised credentials are reused elsewhere.
This vulnerability aligns with CWE-295 Improper Certificate Validation, as the software fails to perform adequate verification of the authenticity of certificates presented during authentication. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts and specifically relates to credential access via interception techniques such as Network Sniffing (T1040) or Man-in-the-Middle attacks (T1557). The failure to strictly enforce SAN precedence over Common Name reflects a broader industry challenge where legacy compatibility features inadvertently weaken security postures. By accepting certificates that do not precisely match the intended server identity, FreeRDP effectively nullifies the primary benefit of public key infrastructure in this context: ensuring that users are communicating with their intended destination and not an impersonator.
Mitigation for this vulnerability requires immediate action to update the FreeRDP installation to version 3.32.2 or later, where these validation logic errors have been corrected to enforce strict SAN matching and disable insecure Common Name fallbacks. Organizations relying on FreeRDP should also review their certificate trust stores to ensure that only necessary Certificate Authorities are trusted, thereby limiting the pool of certificates an attacker could potentially use for interception. Additionally, implementing mutual TLS authentication or using certificate pinning can provide defense-in-depth by ensuring that clients accept connections only from specific, pre-approved server identities regardless of CA validation outcomes. Regular audits of network security configurations and monitoring for anomalous SSL/TLS handshake patterns can further aid in detecting attempts to exploit this flaw before significant data exfiltration occurs.