FreeRDP EUVD-2026-115931

Exploitation requires the FreeRDP client to be used in RD Gateway mode (e.g. /gateway over the HTTP or WebSocket transport) and to connect to an attacker-controlled, compromised, or man-in-the-middled RD Gateway; the malicious gateway then sends one eight-byte RDG header declaring packetLength 0x7FFFFFFF, which is processed in rdg_receive_packet before any tunnel authentication. No credentials or prior authentication on the client are needed (pre-auth), but the attack is limited by the need for the victim to initiate a gateway connection to the hostile endpoint (UI:P), by applying only to RD Gateway deployments rather than direct RDP connections, and by its recoverable nature - if the host refuses the ~2 GiB allocation the connection fails cleanly, and no OOM kill or data-access effect was observed. Updating to FreeRDP 3.32.2 is the fix.

This is a medium-severity, availability-only denial-of-service issue, and the signals are largely consistent rather than conflicting. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L) scores 5.3 and correctly reflects that there is no confidentiality or integrity impact and only a low availability impact. The attack is network-reachable and pre-authentication, but it is not a classic 'remote unauthenticated attacker hits a listening service' case: the victim is a FreeRDP client, and the hostile party is the RD Gateway the client connects to, so exploitation depends on the client reaching a malicious, compromised, or MITM'd gateway (captured by UI:P / user-initiated connection). It is NOT CISA KEV-listed, so it is not confirmed as actively exploited. No EPSS score was supplied, so exploitation probability cannot be quantified from the input. The GHSA advisory includes complete, independently reproduced proof-of-concept code (a measured 2.032 GiB resident allocation from an eight-byte header), so a working public PoC exists even though there is no evidence of in-the-wild use. The vuln.today decision label is 'this_month' (not act_now/emergency), which matches the picture of a credible but non-critical, recoverable client-side DoS. Net: a real issue worth patching on a normal cycle for anyone using RD Gateway, but not an emergency - the impact is temporary memory exhaustion with clean failure if the host refuses the allocation, no OOM kill or data access was observed, and there is no code execution or data exposure.

An attacker who operates, compromises, or man-in-the-middles an RD Gateway waits for a FreeRDP client to connect through it, then sends a single eight-byte RDG header (02 00 00 00 ff ff ff 7f) declaring a packet length of 0x7FFFFFFF before tunnel authentication. The client's rdg_receive_packet passes the INT_MAX check and calls Stream_EnsureCapacity, causing WinPR to allocate and zero-fill roughly 2 GiB while it waits for body bytes the gateway never sends, exhausting client memory. A full working proof-of-concept gateway is published in the FreeRDP GHSA advisory and was independently reproduced over both WebSocket and non-WebSocket HTTP transports.