CVE-2026-66402

CVE-2026-66402 is a certificate validation bypass in FreeRDP containing three distinct flaws: NUL byte truncation in hostname matching, inverted CN-over-SAN precedence, and incorrect IP address matching (applying DNS rules to iPAddress SAN entries). All three stem from the same root cause — FreeRDP implemented custom certificate identity matching rather than using OpenSSL's X509_check_host(), which has existed since OpenSSL 1.0.2 (2015) and handles these edge cases correctly. The NUL truncation is the most severe. FreeRDP's matching code copies certificate Common Name and Subject Alternative Name fields into fixed-size buffers without validating length boundaries. An attacker with a crafted certificate containing a hostname longer than the buffer can truncate the comparison string, enabling spoofed identities. X509_check_host() explicitly guards against this class of bug. The CN-over-SAN inversion is a specification violation. RFC 2818 (2000) is clear: SANs must be checked first, and CN should be used only as a fallback when no SANs are present. FreeRDP checks CN first and ignores SANs entirely. This means a certificate with a valid SAN but mismatched CN would be accepted if the attacker controls the CN — a common scenario in organizational PKI where SANs are the canonical identity field. The IP address matching flaw uses DNS-style wildcard rules (like *.example.com) against iPAddress SAN entries, which are raw binary addresses, not DNS names. This creates false positives when certificate templates use patterns that coincidentally match the byte representation of IP addresses. For defenders: verify your FreeRDP version (affected versions span the past several years; check your vendor advisory for exact boundaries). If you cannot patch immediately, the practical mitigation is enforcing certificate pinning for known RDP endpoints or routing traffic through a proxy that performs correct validation. Network-level controls are your stopgap until the patch deploys. The deeper lesson is architectural: certificate validation is one of the most attackable surfaces in any TLS client, and custom implementations almost invariably get one of these three conditions wrong. The presence of these three specific bugs in a fifteen-year-old codebase suggests the validation code was written once, worked well enough to not crash, and never received the security review that would have caught specification violations like the CN-over-SAN inversion.

Reviewed through automated stages and approved by a human before publication.