FreeRDP CVE-2026-110836

Exploitation requires the FreeRDP client (versions 3.0.0 through 3.31.x) to establish an RDP-over-HTTP gateway connection to a server the attacker controls or has compromised; the attacker then returns an HTTP response carrying a nonzero Content-Length together with an unrecognized, semicolon-containing Content-Type header to drive http_response_recv() into an infinite loop. LIMITING FACTORS: the attacker must control the gateway endpoint the client talks to (not a passive on-path position guaranteed), the victim must actually initiate a gateway-mode connection (UI:P), only gateway-using deployments on the affected version range are exposed, and impact is confined to client-side CPU exhaustion (no code execution, no data compromise).

This is a genuine but moderate-severity availability issue, not a top-tier priority. The authoritative CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 7.1 and correctly reflects a network-reachable, low-complexity, unauthenticated flaw whose ONLY impact is availability (VA:H) via CPU exhaustion - there is no confidentiality or integrity loss (VC:N/VI:N), so this cannot lead to code execution or data theft. The most important signal is the threat model inversion: this is NOT a server/service being attacked by clients, but a CLIENT being attacked by a malicious or compromised RDP gateway (UI:P indicates the victim must initiate a connection). That dramatically narrows real-world exploitability to scenarios where a user is lured or directed to a hostile gateway. No EPSS score, KEV listing, or POC was provided in the input, so there is no evidence of active exploitation or available exploit code - exploitation likelihood should be treated as currently low/unproven. Note one minor tension: the vector marks PR:N (unauthenticated) and the source uses UI:P (passive), but realistically the client user does take the action of connecting, so the practical barrier is 'victim connects to attacker-controlled gateway' rather than fully no-interaction; this does not contradict the score but tempers the 'network, unauthenticated' framing. Overall: patch on normal cadence; it is not an emergency unless gateways in your environment could be attacker-influenced.

A user initiates an RDP session through a gateway that an attacker controls or has compromised (e.g., via DNS/proxy redirection or a rogue gateway). The gateway returns a crafted HTTP response with a nonzero Content-Length and a semicolon-containing, unrecognized Content-Type header, driving http_response_recv() into an infinite loop that pins the FreeRDP client thread at 100% CPU indefinitely. No public exploit code was identified in the provided data; attack complexity is low once the attacker controls the gateway response.