FreeRDP EUVD-2026-101714

Two concrete prerequisites must both hold: (1) the FreeRDP client must have DRIVE REDIRECTION (the rdpdr/drive channel) enabled - a non-default feature a user must opt into - and (2) the victim client must establish a session to an attacker-controlled or compromised RDP server (reflected as UI:P / user interaction in the CVSS vector). The trigger is a server-sent IRP_MJ_CREATE with AllocationSize = UINT64_MAX, which makes the allocation-size seek fail after the opened local file has already been registered in the drive dictionary. Limiting factors: the attacker is the SERVER, not a remote scanner, so the victim must be enticed to connect; impact is bounded to leaked handles/file objects on the client that are reclaimed at drive teardown (disconnect), with no confidentiality or integrity effect; only FreeRDP 3.13.0 through before 3.32.0 are affected.

This is a genuinely medium/low-priority issue, consistent with its CVSS 4.0 base score of 5.3. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L) describes a client-side flaw with no confidentiality or integrity impact and only LOW availability impact - a gradual file-handle/file-object leak that persists until drive teardown (session disconnect), not a crash or remote code execution. The 'network, no-privilege' metrics overstate the practical risk: this is a malicious-SERVER-attacks-CLIENT scenario (reflected in UI:P), so an attacker must first induce a victim to connect their FreeRDP-based client - with drive redirection enabled - to a server the attacker controls. No EPSS score, KEV listing, or POC was provided in the input; there is no public exploit identified at time of analysis and no evidence of active exploitation. The signals are internally consistent (low-severity resource leak requiring victim interaction and a non-default feature), so there is no priority inflation here - this is a hardening/stability fix rather than an urgent patch, though handle exhaustion over a long-lived session could degrade a client host.

An attacker stands up a malicious RDP server and lures a user to connect their FreeRDP-based client (with drive redirection enabled) to it - for example via a crafted .rdp file or a compromised/typosquatted remote-desktop endpoint. The server repeatedly sends IRP_MJ_CREATE requests with AllocationSize set to UINT64_MAX, each forcing the seek to fail after the file has been registered, steadily leaking file objects and OS handles on the client until the drive channel is torn down. No public exploit code was provided in the input.