FreeRDP EUVD-2026-98652

Exploitation requires the victim to be running FreeRDP 3.0.0 through 3.31.x as a client AND to establish an RDP session to an attacker-controlled or compromised server (UI:P - the victim initiates the connection). The vulnerable code path is in smartcard redirection, so the client must have smartcard/device redirection enabled for the SCardTransmit request to reach smartcard_Transmit_Call; the malicious server must send a transmit request with an invalid card handle and a nonzero receive length. Limiting factors: no attacker-side authentication is needed, but the attack is server-to-client (reverse of typical RDP threat models), depends on user-initiated connection to a hostile endpoint, and the smartcard redirection feature being active; impact is confined to disclosure of client heap memory with no code execution or service disruption.

This is a medium-severity (CVSS 4.0 base 5.3) client-side information disclosure, and the available signals converge on it being a genuine but non-urgent issue rather than a top-priority emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:L) shows network reach and no authentication, but two factors cap real-world risk: UI:P means the victim client must actively connect to the attacker-controlled server, and VC:L reflects that the impact is limited, bounded leakage of up to 66,560 uninitialized heap bytes (CWE-200) with no integrity or availability impact. No EPSS score, KEV listing, or POC/exploit code is present in the supplied data, so exploitation status is 'no public exploit identified at time of analysis'. There is no conflict between the signals, but note the input provides only a CVSS 4.0 vector (no 3.1 vector or EPSS), so probabilistic exploitation likelihood cannot be quantified from the data given. The practical risk is heightened only for environments that use FreeRDP with smartcard redirection enabled and whose users connect to untrusted or compromised RDP servers.

An attacker stands up or compromises an RDP server and lures a FreeRDP user (with smartcard redirection enabled) to connect to it. During the smartcard channel exchange the malicious server sends an SCardTransmit request carrying an invalid card handle and a nonzero receive length, causing the client to serialize and return large chunks of uninitialized heap memory back to the server. No public exploit code is identified at time of analysis, but the flaw is simple to trigger for an actor controlling the server side.