FreeRDP shadow server CVE-2026-121404

Requires an authenticated RDP session (PR:L) to a FreeRDP shadow server specifically (e.g. freerdp-shadow-cli), not an ordinary FreeRDP client deployment. The server must have opened the dynamic virtual channel and the client must complete channel creation on audin (started per-client by stock shadow) or rdpgfx (started when graphics is negotiated); an unknown or unopened channel never reaches the vulnerable queue. The attacker must emit a drdynvc DATA PDU with a valid channel ID and zero-length payload - which the stock xfreerdp client refuses to produce, so a modified client or post-serialization PDU shaper (as in the advisory PoC) is required. Limiting factors: valid credentials needed, shadow-server deployment mode required, only audin/rdpgfx readers are reachable in stock shadow (ainput, disp, echo, telemetry and others use the same pattern but are not started), and the spin ends immediately on client disconnect.

This is a genuine but bounded availability risk, not a widespread emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 7.1 score are driven entirely by availability impact (VC:N/VI:N/VA:H) - the advisory explicitly states no crash, memory corruption, or disclosure was demonstrated, so confidentiality and integrity are untouched. PR:L confirms the attacker must be an authenticated RDP client, which meaningfully limits exposure versus an unauthenticated flaw. No EPSS score and no CISA KEV entry were provided in the input, so there is no evidence of active exploitation; the only exploitation signal is the detailed proof-of-concept bundled in the vendor GHSA advisory. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with an authenticated, impact-limited DoS. A notable caveat: the impact is CPU exhaustion of one-to-two cores per malicious session (measured ~1 and ~2 cores for audin and rdpgfx respectively), and the advisory states no many-session exhaustion test was run - so full-server denial of service at scale is plausible but unverified. Overall this warrants prompt patching where FreeRDP shadow server is deployed, but it is a lower-urgency, availability-only issue rather than a drop-everything critical.

An authenticated user connects to a FreeRDP shadow server (freerdp-shadow-cli), lets the server open the audin and/or rdpgfx dynamic channels, then sends a drdynvc DATA PDU carrying a valid channel ID but zero application payload. The server queues the empty message, FreeRDP_WTSVirtualChannelRead never consumes it, and the reader thread spins a full CPU core until the client disconnects. A complete proof-of-concept - an LD_PRELOAD PDU shaper plus a loopback runner - is published in the vendor advisory, since the stock xfreerdp client refuses to send zero-length DVC writes and must be mutated post-serialization.