This is a heap overflow in FreeRDP's clipboard handling (cliprdrStream_Read) that stems from a fundamental trust boundary error: the code fetches content using the server-supplied file size, then copies the entire response into the caller's buffer without checking whether that buffer can actually hold it.
The vulnerability sits at the intersection of two interfaces with different contracts. The IStream::Read() method is called with a caller-allocated buffer of size cb and must copy no more than cb bytes. But the FreeRDP client fetches content from the RDP server using the server's declared file size (req_fsize), then ignores the caller's buffer capacity entirely. The result is a heap overflow when the server-supplies a size larger than the caller's buffer.
This is a trust migration flaw: the code likely evolved from clipboard file caching that assumed a cooperative server, then got retrofitted for network I/O without re-anchoring the trust boundary. The server-supplied size became implicitly trusted because that assumption was never made explicit.
Exploitation requires a malicious or compromised RDP server — the client must connect to a hostile endpoint. This is not a client-side bug you trigger by connecting to a legitimate server. The practical exploitability hinges on attack surfaces like compromised MSP infrastructure, supply chain compromises of RDP servers, or lateral movement scenarios where an attacker already controls one side of an RDP session. The clipboard is a universal data bus in Windows — every copy-paste operation routes through it, making credential and data exfiltration trivial post-exploitation.
For defenders: prioritize patching FreeRDP clients that connect to untrusted RDP servers, particularly in MSP or shared infrastructure environments. Audit other IStream wrappers in the codebase for the same pattern — server-supplied lengths being trusted over caller buffer sizes. The fix must enforce that the client reads no more than min(cb, actual_response_length) and handles truncation gracefully rather than trusting the server's size declaration.