FreeRDP CVE-2026-121403

Requires that the FreeRDP client has drive redirection enabled (via /drive or drivestoredirect) AND is running the default asynchronous RDPDR dispatch mode - both conditions the advisory names explicitly. The victim must also initiate a connection to the attacker-controlled or compromised RDP server (UI:P / user interaction), since this is a server-to-client attack, not an attack on a listening service. LIMITING FACTORS: the non-default synchronous static-channel setting propagates the handler error and prevents the unbounded asynchronous queue, so it is not exploitable; impact is confined to the affected session (availability only, no data disclosure or modification); and affected builds are FreeRDP ≤ 3.32.1.

This is a genuine but moderate-priority issue, not a high-CVSS-but-low-risk artifact and not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L) and the 5.3 score correctly frame it: network-reachable, low complexity, no attacker privileges, but requiring victim interaction (UI:P) and causing only limited availability impact (VA:L) with no confidentiality or integrity loss. Critically, the attack direction is server-to-client: a malicious or compromised RDP server attacks a FreeRDP client that connects to it, so 'AV:N / PR:N' describes the server needing no credentials, not a classic internet-facing listener being hit. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no signal of widespread or active exploitation. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a medium-severity availability bug. A public PoC exists but it is an in-process verification harness, not a demonstrated remote exploit (see confidence_notes). Net: patch on a normal cadence; it is not a drop-everything issue, but it is a real, confirmed availability defect for clients that use drive redirection.

A FreeRDP user with drive redirection enabled connects to an attacker-controlled or compromised RDP server. The server sends a drive DEVICE_IOREQUEST with a valid 20-byte header specifying IRP_MJ_CREATE but no CREATE body; this is rejected deep in processing and silently terminates the drive worker thread, after which the server floods further IRPs that accumulate unbounded in the IrpQueue until memory is exhausted and the session's availability is lost. A public verification harness demonstrating the worker death and unbounded queue retention is published in the advisory, but it posts IRPs locally rather than running a malicious server, so it is not a verified working remote exploit.