FreeRDP EUVD-2026-106997

Exploitation requires the victim to run a FreeRDP client (3.0.0 through 3.31.x) with the smartcard emulation backend active and to connect to an attacker-controlled or compromised RDP server - the attack is server-to-client, not the usual client-to-server direction. The specific trigger is a server-supplied SCardGetStatusChange reader-state entry whose szReader (per-reader name) field is null, which the client passes to strcmp/_wcscmp. Limiting factors: passive user interaction is needed (the user must initiate/accept an RDP session to the malicious endpoint, per UI:P), exploitation depends on smartcard channel/emulation being negotiated, and the impact is limited to crashing the client process (no code execution, no data disclosure).

This is a client-side denial-of-service (CWE-476 null-pointer dereference) with a genuinely moderate, not critical, real-world risk profile. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 7.1 driven entirely by VA:H (availability) with zero confidentiality or integrity impact (VC:N/VI:N) - consistent with the description's crash-only outcome. The critical limiting signal is the threat model inversion: this is NOT a server being attacked by a client, but a FreeRDP *client* being crashed by a *malicious or compromised RDP server* it connects to (reflected in UI:P/UI:R - the victim must initiate a connection). No EPSS score, KEV listing, or POC was provided; per the input this is 'no public exploit identified at time of analysis.' There is no active-exploitation signal to elevate priority. The impact ceiling is a crashed client process, not RCE or data loss, so despite the 7.1 'High' label this is a low-to-moderate operational priority - patch in routine cycles rather than emergency. One caveat to verify with the vendor: exploitation appears to require the smartcard emulation backend to be in use, which the raw CVSS AC:L does not capture.

A victim uses a FreeRDP-based client (version 3.0.0-3.31.x) to connect to an RDP server controlled or compromised by an attacker. During smartcard emulation handshaking, the malicious server returns a crafted SCardGetStatusChange reader-state entry with a null szReader field; when the client calls strcmp/_wcscmp on the null per-reader name it dereferences the null pointer and the client process crashes. No public exploit code was provided in the intelligence set.