FreeRDP EUVD-2026-115940

Exploitation requires the FreeRDP client to be started with USB redirection enabled (/usb), a matching local USB device being announced at connect time, and a malicious or compromised RDP server that sends a dynamic-virtual-channel CLOSE_REQUEST for the urbdrc control channel. The server's close must land in the narrow window between FindChannelById returning the unreferenced pointer and the announcement thread reading channel->Write, because the control-channel close path does not take the device-manager loading_lock. Limiting factors: the victim must initiate the connection and opt into USB redirection (non-default), the race is timing-dependent (AC:H/AT:P), and the demonstrated outcome is only a client crash - no confidentiality, integrity or code execution was shown. The device-channel variant is serialized by a separate lock and is not affected.

The input CVSS 4.0 vector (CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, score 6.0/MEDIUM) describes a network-reachable but hard-to-trigger flaw: AC:H plus AT:P reflect the CWE-362 race window between the lookup and the write, and UI:P reflects that the victim must connect to the malicious server and have USB redirection active. Impact is availability-only (VA:H; VC/VI = N), consistent with the advisory which states no confidentiality loss, no integrity loss and no demonstrated RCE - the demonstrated outcome is a client crash. The vuln.today Decision label is 'this_month' (not act_now/emergency), VulnCheck is the reporter, and the source is a FreeRDP GHSA advisory. No EPSS score is provided in the input and the CVE is not listed in CISA KEV, so there is no confirmed active exploitation. A public PoC reference exists in the form of a focused ASan harness that includes the real drdynvc translation unit and reproduces the heap-use-after-free read of the eight-byte Write pointer (and a harness-forced same-slot indirect call); it is not verified as working end-to-end exploit code, and the advisory explicitly says a live USB race and server-directed memory reclamation have not been shown. On balance this is a real but lower-tier priority: the attack requires a malicious/compromised server, a non-default client configuration, a matching local USB device and a precise timing race, and yields a crash rather than code execution - matching the 'this_month' triage rather than an emergency.

A victim running FreeRDP with USB redirection (/usb) enabled connects to an attacker-controlled or compromised RDP server while a matching local USB device is being announced. The server sends a dynamic-virtual-channel CLOSE_REQUEST for the USB redirection control channel, timed to race the libusb announcement thread so the channel is freed before the thread reads channel->Write, producing a use-after-free and a client crash. A focused ASan harness publicly demonstrates the use-after-free using real FreeRDP code, but no end-to-end stock-client exploit has been observed.