CVE-2026-32105: 
xrdp vulnerability analysis and mitigation

CVE-2026-32105 is a missing MAC verification vulnerability in xrdp, an open-source RDP server, that allows unauthenticated man-in-the-middle (MITM) attackers to modify encrypted RDP traffic in transit without detection. It affects all xrdp versions through 0.10.5 when using the "Classic RDP Security" layer; connections using TLS are not affected. The vulnerability was published on April 17, 2026, and fixed in xrdp version 0.10.6 released the same day. It carries a CVSS v3.1 base score of 7.7 (High) and a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory, Red Hat).

The root cause is classified as CWE-354 (Improper Validation of Integrity Check Value) and CWE-347 (Improper Verification of Cryptographic Signature). While xrdp correctly generates the 8-byte MAC integrity signature when sending RDP packets under the Classic RDP Security layer, the receiving logic entirely omits the validation step — the signature is silently ignored rather than verified. This means an attacker positioned as a MITM on the network path between an RDP client and the xrdp server can intercept, modify, and re-inject encrypted RDP packets without the server or client detecting the tampering. The vulnerability requires no authentication and no user interaction, but does require the attacker to have network-level MITM capability and that the connection uses Classic RDP Security rather than TLS (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation allows an unauthenticated MITM attacker to silently tamper with encrypted RDP session traffic, resulting in high integrity and confidentiality impact on both the vulnerable and subsequent systems, with low availability impact. An attacker could manipulate RDP session data — including keystrokes, screen content, clipboard data, and authentication exchanges — without either endpoint detecting the modification. This could facilitate credential theft, session hijacking, or injection of malicious commands into an active RDP session (GitHub Advisory, Feedly).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.044%, indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to have MITM network positioning, which raises the practical bar compared to fully remote, unauthenticated vulnerabilities. The vulnerability was credited to researchers @exploitintel, @smittix, and @hessandrew (xrdp v0.10.6 Release).

1. Reconnaissance: Identify targets running xrdp (versions ≤ 0.10.5) with Classic RDP Security enabled (not TLS). Tools like Nmap with RDP service detection (nmap -p 3389 --script rdp-enum-encryption) can identify servers advertising Classic RDP Security.
2. Establish MITM position: Position between the RDP client and xrdp server using ARP spoofing, DNS poisoning, rogue Wi-Fi access point, or BGP hijacking to intercept network traffic on the RDP port (default TCP 3389).
3. Intercept RDP traffic: Capture the RDP session stream. Since Classic RDP Security encrypts traffic but does not enforce MAC validation on the receiving end, the attacker can observe and manipulate the encrypted packet stream.
4. Modify encrypted packets: Alter the payload bytes of intercepted RDP packets (e.g., modifying keystrokes or injected commands). Because xrdp's receiving logic ignores the 8-byte MAC signature, modified packets pass through without triggering any integrity error.
5. Achieve objective: Depending on the attacker's goal, inject malicious keystrokes into the session, exfiltrate session content, or manipulate authentication data — all without detection by either the client or server (GitHub Advisory, Red Hat Bugzilla).

• Network: Unexpected ARP table changes or duplicate MAC addresses on the network segment hosting xrdp servers, suggesting ARP spoofing; anomalous traffic routing through unexpected intermediate hosts on TCP port 3389; RDP connections negotiating Classic RDP Security (not TLS) where TLS would normally be expected.
• Logs: xrdp session logs (/var/log/xrdp.log, /var/log/xrdp-sesman.log) showing connections using security_layer=rdp (Classic RDP Security) rather than TLS; unexpected session activity or commands inconsistent with the legitimate user's behavior.
• Process/Session: Unusual commands or keystrokes appearing in RDP session recordings that the legitimate user did not initiate; clipboard content changes not initiated by the user.
• Configuration: Review of xrdp.ini showing security_layer not set to tls, confirming exposure to this vulnerability (GitHub Advisory).

The primary remediation is to upgrade xrdp to version 0.10.6 or later, which implements proper MAC signature verification for Classic RDP Security packets (xrdp v0.10.6 Release). For organizations unable to upgrade immediately, the recommended workaround is to configure xrdp.ini to enforce TLS security by setting security_layer=tls, which ensures end-to-end integrity and is not affected by this vulnerability (GitHub Advisory). Additionally, network-level controls such as restricting RDP access to trusted networks, using VPNs, and monitoring for MITM indicators can reduce exposure risk.

The vulnerability was disclosed on April 17, 2026, and quickly tracked by major vulnerability databases and security vendors including Red Hat, Tenable (Nessus plugin 307453), Qualys, and FreeBSD's VuXML (Red Hat, Feedly). The xrdp v0.10.6 release addressed multiple CVEs simultaneously, suggesting a coordinated security release. Social media activity was limited to automated CVE tracking accounts on Bluesky and Mastodon/Infosec.exchange, with no notable researcher commentary or significant community debate observed. OpenSUSE and Fedora subsequently issued security updates incorporating the fix (Feedly).