FreeRDP EUVD-2026-98707

Exploitation requires the victim FreeRDP client to establish an RDP connection routed through an RD Gateway that is attacker-controlled or already compromised/MITM'd; the malicious gateway then returns a header-only PKT_TYPE_CLOSE_CHANNEL packet with no payload. Limiting factors: the attacker must occupy the gateway position (not an arbitrary remote host), the user must initiate the connection (UI:P / UI:R), the client must run FreeRDP 2.3.0 through 3.31.x, and the gateway/RDG transport path must be in use. Impact is limited to crashing the client process (denial of service) - no code execution, data disclosure, or integrity loss.

This is a genuine but bounded availability-only issue, not a top-tier priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H, base 7.1) correctly captures that exploitation is network-reachable and low-complexity but requires passive user interaction (UI:P) - the victim FreeRDP client must initiate a connection through the attacker's RD Gateway - and the impact is confined to availability (VA:H), with zero confidentiality or integrity effect. That is the defining caveat: the attacker is not a random remote party but 'a malicious or compromised RD Gateway,' so the real-world attacker model is either an operator of a hostile gateway or an adversary who has already compromised/MITM'd the gateway a client is steered toward. No EPSS score, KEV listing, SSVC decision, or POC was supplied in the intelligence, so exploitation-probability signals are absent rather than low - do not read the missing EPSS as 'low risk,' it is simply not provided. Reported by VulnCheck with a FreeRDP GHSA advisory, the defect itself is well-corroborated, but there is no evidence of exploitation and the payoff (a client crash) is low, so this should be patched on a normal cadence rather than treated as an emergency.

An attacker who operates or has compromised an RD Gateway waits for a FreeRDP client (2.3.0 up to but not including 3.32.0) to connect through it. The gateway replies with a bare eight-byte PKT_TYPE_CLOSE_CHANNEL header carrying no payload; rdg_process_control_packet forwards the null payload to rdg_process_close_packet, which dereferences the NULL stream and crashes the client. No public exploit code was identified in the provided data, but the trigger is a single crafted header and is trivial to reproduce.