---
id: "CVE-2026-111382"
kind: "vulnerability"
aliases: ["CVE-2026-111382"]
title: "FreeRDP: malicious server frames corrupt client heap, enabling code execution"
severity: "high"
cvss: 8.8
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "freerdp", "fixed": ["3.32.0"], "affected": "< 3.32.0", "ecosystem": "vendor"}, {"name": "freerdp", "fixed": ["3.32.0"], "affected": "<= 3.31.1 (< 3.32.0)", "ecosystem": "vendor"}]
ecosystems: ["vendor"]
tags: ["client-side", "freerdp", "linux", "package", "rdp-clients", "windows"]
not_affected_if: ["fixed-version", "no-outbound-rdp", "no-rdp-connections-to-untrusted-servers", "patched-3.32.0", "trusted-servers-only"]
published_at: "2026-10-16T03:18:05+00:00"
first_seen_at: "2026-10-23T21:57:12+00:00"
updated_at: "2026-10-24T00:29:00+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111382", "first_seen_at": "2026-10-23T21:57:12+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-24T00:29:00+00:00"}]
---

# FreeRDP: malicious server frames corrupt client heap, enabling code execution

FreeRDP clients up to 3.31.1 write one row past the heap U/V planes in general_LumaToYUV444 and general_ChromaV2ToYUV444. This happens when a malicious RDP server sends an RDPGFX AVC444 or AVC444v2 frame whose region rect has an odd height and ends at the surface height. It corrupts client heap memory and can lead to code execution as the connecting user. The user has to connect to the hostile or compromised server. Fixed in 3.32.0.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:freerdp affected < 3.32.0 fixed 3.32.0
- vendor:freerdp affected <= 3.31.1 (< 3.32.0) fixed 3.32.0

## How to check

Run xfreerdp /version (or wlfreerdp, sdl-freerdp). Anything below 3.32.0 is affected, and so are apps that bundle libfreerdp. On Debian or Ubuntu run dpkg -l 'freerdp*' or 'libfreerdp*'. On RPM distros run rpm -q freerdp. Clients with no H.264/AVC support built in, or that never connect to untrusted servers, are less exposed. I did not confirm the default AVC444 setting.

## Fix

Upgrade FreeRDP to 3.32.0 or later. Ubuntu 24.04: freerdp3 3.32.0+dfsg-0ubuntu0.24.04.1. Debian: forky/sid fixed in freerdp3 3.32.0+dfsg-1 (sid now 3.32.2+dfsg-1); trixie (3.15.0+dfsg-2.1+deb13u3) and bookworm freerdp2 (2.11.7) still listed vulnerable. Until patched, only connect to trusted servers; disabling AVC444 (e.g. /gfx:AVC420 or -gfx-h264) is a possible workaround, which I did not verify in a source.

## Timeline

- 2026-10-23T21:57:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-111382
- 2026-10-24T00:29:00+00:00 analyst — Read maintainer GHSA-f4pf-pgp4-f2r3 (fixed 3.32.0, affects <=3.31.1), Debian tracker, Red Hat, Snyk/Ubuntu. Not exploited as far as sources say; PoC is only described in the advisory (malicious server CreateSurface 64x16 + AVC444 rect {0,1,64,16}), no public exploit code found; no X conversation. Whether AVC444 is on by default in clients NOT confirmed: advisory says all H.264 backends are affected but not the default setting.

## Documents

- [advisory] GHSA-f4pf-pgp4-f2r3 FreeRDP AVC444 heap OOB write https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-f4pf-pgp4-f2r3
- [fix] Debian tracker CVE-2026-111382 https://security-tracker.debian.org/tracker/CVE-2026-111382
- [fix] Snyk/Ubuntu 24.04 freerdp3 fix https://security.snyk.io/vuln/SNYK-UBUNTU2404-FREERDP3-21010300
- [mentions] Red Hat CVE-2026-111382 https://access.redhat.com/security/cve/cve-2026-111382

## From the sources

FreeRDP before 3.32.0 contains a client-side heap out-of-bounds write vulnerability in general_LumaToYUV444 and general_ChromaV2ToYUV444 that allows malicious RDP servers to corrupt client memory. Attackers can send RDPGFX AVC444 or AVC444v2 frames with odd-height region rects ending at surface height to write past U/V planes, enabling heap corruption and potential code execution.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_