- The Mess: FreeRDP patched CVE-2026-91964, a heap-based buffer overflow in the RDP negotiation code. A malicious RDP server can feed the client an oversized redirection token and smash a fixed 512-byte heap buffer.
- The Damage: The bug can crash FreeRDP clients and, when chained with a separate memory-disclosure primitive, can be turned into remote code execution on the victim’s machine.
- The Fix: Upgrade FreeRDP to 3.31.0 or later and stop connecting vulnerable clients to untrusted RDP servers.
The RDP client is where the exploit lands
CVE-2026-91964 is not a vulnerability in an RDP server.
It is a vulnerability in the FreeRDP client.
That changes the attack model completely.
The attacker controls the RDP server.
The victim connects to it.
The server sends specially crafted redirection data.
FreeRDP processes it.
Then the heap gets corrupted.
The official FreeRDP advisory rates the vulnerability High, with a CVSS 3.1 score of 8.8. The vector requires user interaction because the victim needs to connect to the malicious server.
The vulnerable versions cover the 2.x line and 3.x versions through 3.30.0.
The fixed release is:
FreeRDP 3.31.0
The attacker controls the data
The bug lives in the handling of the RDP Server Redirection PDU.
A malicious RDP server can control the LB_LOAD_BALANCE_INFO field.
FreeRDP stores that field together with its attacker-controlled length.
The important part is that the length isn’t properly constrained before the data eventually reaches the vulnerable negotiation code.
The attack chain looks roughly like this:
malicious RDP server
→ Server Redirection PDU
→ attacker-controlled LoadBalanceInfo
→ RoutingToken
→ nego_send_negotiation_request()
→ heap buffer overflow
The server controls the bytes.
It also controls the length.
That is exactly the combination you do not want anywhere near a fixed-size memory buffer.
The 512-byte buffer is the smoking gun
The FreeRDP advisory documents the vulnerable code path in detail.
The negotiation layer allocates a stream with a fixed size of 512 bytes.
The code then writes the attacker-controlled routing token into that stream without ensuring that enough capacity remains.
The advisory estimates that only around 501 bytes are available after the negotiation header.
Anything larger runs past the allocation.
This is classic memory corruption:
attacker-controlled length > destination capacity
There is no magic involved.
No complicated parser differential.
No obscure cryptographic failure.
Just a missing bounds check on attacker-controlled data.
The redirection makes the attack more interesting
The malicious data does not simply disappear after the initial packet.
FreeRDP stores the server-controlled LoadBalanceInfo.
When the client reconnects following the redirection, that stored value becomes the RoutingToken used by the negotiation layer.
So the vulnerable data flow is effectively:
server-controlled field → persistent client setting → negotiation token → fixed buffer
That gives the attacker a clean path from the network protocol into the vulnerable memory operation.
What happens after the overflow?
This is where the FreeRDP advisory gets considerably more interesting than the usual CVE summary.
The researchers found that the heap allocation immediately following the negotiation buffer can be a clipboard-related hash table under the tested Linux configuration.
The overflow can therefore overwrite fields in that structure.
During client shutdown, FreeRDP eventually frees that hash table.
The corrupted function-pointer-related data can then redirect execution.
The researchers demonstrated:
RCE with id = root
on their tested Linux FreeRDP client.
The tested environment used FreeRDP development code with ASLR and NX enabled.
That is a significant finding.
But there is an important qualification.
CVE-2026-91964 alone is not the whole RCE chain
The advisory explicitly says that remote code execution requires chaining this overflow with a separate memory-leak vulnerability.
Without the leak, the same bug is described as a denial-of-service condition because exploitation is hindered by memory-layout randomization.
That distinction matters.
The correct description is not:
“Anyone can instantly get RCE just by sending an RDP packet.”
The technically accurate description is:
A malicious RDP server can trigger a heap overflow in vulnerable FreeRDP clients. The researchers demonstrated RCE when the overflow is combined with a separate memory-disclosure primitive.
That’s still nasty.
It just isn’t the same thing as a standalone reliable RCE.
The victim has to connect
CVSS reflects this.
The official vector is:
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
The attacker does not need credentials.
The attack comes over the network.
But user interaction is required.
That means the practical attack scenarios include things such as:
- a user being tricked into connecting to a malicious RDP endpoint,
- an attacker controlling an RDP server the victim already trusts,
- malicious infrastructure used in phishing campaigns,
- compromised RDP gateways,
- redirection from an initially trusted endpoint to an attacker-controlled server.
The final scenario is particularly interesting because RDP redirection is itself a legitimate protocol feature.
The client is designed to follow server-provided instructions.
The vulnerability abuses what happens when those instructions contain oversized data.
Remmina is affected too
This is not necessarily limited to people who run xfreerdp directly.
The FreeRDP advisory states that Remmina 1.4.x is affected through the system libfreerdp library because Remmina does not ship its own RDP implementation.
Other software linking against the FreeRDP client library is also potentially affected.
The advisory specifically mentions:
- GNOME Connections
- KRDC
- Apache Guacamole
guacd
The researchers did not verify every product and version individually, so administrators should check the actual FreeRDP library version rather than assuming a frontend is safe.
That is an important supply-chain angle.
A user may never have installed xfreerdp.
The vulnerable library can still be sitting underneath the GUI application they actually use.
Linux desktop users should pay attention
The published RCE demonstration was performed on:
- Ubuntu 26.04
- glibc 2.43-2ubuntu2
- FreeRDP development build
- ASLR enabled
- NX enabled
The researchers achieved code execution as root in that test environment.
That doesn’t mean every Linux distribution or every FreeRDP application is immediately exploitable in exactly the same way.
Heap layout, compiler options, library versions, build configuration and enabled features all matter.
But the demonstration proves that the vulnerable memory corruption is not merely theoretical.
Debian is still showing vulnerable packages
Debian’s security tracker currently lists vulnerable FreeRDP packages for supported branches while tracking 3.31.0 as the upstream fixed version.
That is another reason not to blindly run:
xfreerdp --version
and assume the result maps directly to the upstream release.
Distribution packages can carry backports and version-specific fixes.
For enterprise systems, check the distribution’s security advisory as well as the upstream FreeRDP version.
What administrators should do
1. Upgrade FreeRDP
The upstream fix is:
3.31.0
Upgrade every FreeRDP client and library that can process untrusted RDP server responses.
2. Check applications using libfreerdp
Inventory software that depends on FreeRDP.
At minimum, check systems using:
- FreeRDP,
- Remmina,
- GNOME Connections,
- KRDC,
- Apache Guacamole.
The vulnerable component may be a shared library rather than the application users launch directly.
3. Stop connecting vulnerable clients to untrusted servers
Until patched, avoid RDP connections to servers that aren’t fully trusted.
This isn’t a permanent mitigation.
It simply removes the attacker-controlled server from the equation.
4. Review RDP redirection
Organizations using RDP brokers, load balancing or redirection should understand where clients are being sent.
A trusted initial endpoint does not automatically mean every redirected endpoint deserves the same trust.
5. Patch the second vulnerability too
The FreeRDP researchers explicitly mention a separate memory-disclosure primitive used to turn the overflow into RCE.
If your environment contains multiple FreeRDP security advisories, don’t patch only the CVE that made the headlines.
Review the complete security update set.
This is a client-side RDP problem
That distinction deserves repeating.
Most administrators hear “RDP vulnerability” and immediately think:
Windows Server listening on TCP 3389.
This isn’t that.
The vulnerable component is the client.
The attacker wants the victim to connect to their server.
That makes the affected population different:
RDP server vulnerability
versus
RDP client vulnerability
CVE-2026-91964 belongs to the second category.
That means endpoint management becomes part of the remediation strategy.
The protocol itself isn’t the problem
RDP redirection exists for legitimate reasons.
Large environments use connection brokers and load balancing.
A server can tell the client to connect elsewhere.
That functionality isn’t inherently dangerous.
The problem is that attacker-controlled redirection data eventually reaches a fixed-size buffer without adequate bounds checking.
This is exactly why protocol parsers need hostile-input testing.
The legitimate input can be perfectly valid.
The malicious input simply makes it much larger than the developer expected.
No known active exploitation
As of the current vulnerability records, CVE-2026-91964 is not listed in CISA KEV, and there is no reliable public evidence in the sources checked here that it is being actively exploited.
That’s worth stating because the technical RCE demonstration can otherwise make the issue sound like an active campaign.
It isn’t currently documented that way.
The more immediate concern is that the advisory contains enough technical detail to make the vulnerable code path understandable, while the affected software is widely embedded in Linux remote-desktop tooling.
Bugstoday’s take
FreeRDP just demonstrated why an RDP client should never blindly trust what an RDP server sends back.
CVE-2026-91964 is a straightforward heap overflow.
The interesting part is what sits behind it:
malicious server → redirection → oversized RoutingToken → heap corruption → potential code execution
The researchers already demonstrated root-level RCE when the bug is chained with a memory leak.
So don’t wait for an exploit kit to make this interesting.
Upgrade to 3.31.0.
Then check every application quietly linking against libfreerdp.
Because sometimes the vulnerable software isn’t the application you installed.
It’s the library underneath it.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- FreeRDP — GHSA-2vf2-grvj-6g8x
- CVE-2026-91964
- Debian Security Tracker — CVE-2026-91964
- FreeRDP project security advisory and source code
