It’s not every day a bug in a foundational remote desktop protocol stack can lead to full system compromise. Yet, that’s precisely the situation Kaspersky’s researchers stumbled upon, digging into the widely-used xrdp server. The vulnerability, cataloged as CVE-2025-68670, isn’t some obscure, zero-day whisper; it’s a practical demonstration of how seemingly innocuous data handling can create serious security holes. And the culprit? A poorly managed string conversion.
The unassuming module that led to discovery
This wasn’t some broad, random scan. Kaspersky’s audit focused on their own Kaspersky USB Redirector, a module designed to enhance the functionality of xrdp by allowing local USB devices to be accessed over a remote session. Think flash drives, smart cards, printers—all usable as if they were physically plugged into the remote machine. It’s a handy piece of tech for environments using thin clients, streamlining device management. But in the process of ensuring the security of their product, they found a significant weakness in the upstream component it relied on: xrdp itself.
The fix was swift, a proof to good disclosure practices. The xrdp maintainers patched it in version 0.10.5 and even backported the solution to older, still-supported versions (0.9.27 and 0.10.4.1), coupled with a security bulletin. But how exactly does a string conversion allow remote code execution?
Client data transmission via RDP: A close look
The Remote Desktop Protocol (RDP) connection is, as you might expect, a bit of a dance. There are multiple stages, handshakes, and data exchanges. For CVE-2025-68670, the critical moment occurs before user authentication, during what’s called the Secure Settings Exchange. This is where the client, as part of its initial information packet (a PDU, or protocol data unit), sends credentials and other client-specific details to the server.
These details are packed into a TS_INFO_PACKET structure. Within this structure, fields like username, password, domain, and program path are represented as Unicode strings, with a maximum length of 512 bytes, each terminated by a null character. In the xrdp codebase, this maps to the xrdp_client_info structure, where each character array is defined with INFO_CLIENT_MAX_CB_LEN, which, as the name implies, is precisely 512 bytes.
The client typically transmits this data using UTF-16 encoding. The server’s job, before storing this information, is to convert it to UTF-8. And this is where the wheels can come off.
The conversion process involves a function like ts_info_utf16_in, which reads the UTF-16 data and passes it to in_utf16_le_fixed_as_utf8 for the actual transformation. The intent is clear: prevent buffer overflows. The code snippet shows a check if (num_chars > dst_len) — a seemingly sensible safeguard against writing more data than the destination buffer can hold.
The core of the vulnerability lies in the interaction between the UTF-16 to UTF-8 conversion and how the server handles the length of the converted string, especially when combined with the fixed-size buffers.
But here’s the rub, the very architectural quirk that enables the exploit. The in_utf16_le_fixed_as_utf8_proc function, responsible for the heavy lifting of character conversion, has a peculiar way of handling insufficient buffer space. Look at line [4] in the provided code: if (u8len + 1 <= vn). This condition checks if there’s enough room for the converted UTF-8 character plus a null terminator in the remaining output buffer (vn). If this condition fails, the code simply skips writing the character and adds its length to a counter (r v += u8len).
This “skip and count” behavior is the Achilles’ heel. It means that if a UTF-16 character expands into a longer UTF-8 sequence, and that expansion exceeds the available space in the destination buffer, the character is effectively dropped—but the code still records that bytes were consumed from the input stream. The crucial detail is that the buffer overflow check (if (num_chars > dst_len)) within ts_info_utf16_in only checks the total number of characters processed, not the actual number of bytes written to the destination buffer after potentially skipping some characters due to size constraints.
So, an attacker can craft a UTF-16 string that, when converted to UTF-8, produces character sequences longer than expected. By carefully controlling the input length and its contents, they can trick the server into believing it has successfully converted and stored a string that, in reality, has been truncated mid-conversion or had entire characters dropped. The null terminator, if it’s supposed to be appended after the last valid character, might end up being written into a memory location after the intended buffer, or worse, not written at all if the input is malformed in specific ways. This desynchronization between expected length and actual written data, particularly around the null terminator, is what can be exploited.
Why this matters: A historical echo
This isn’t entirely new territory. We’ve seen vulnerabilities exploited through similar logic errors in string handling and data conversion for decades. The fundamental lesson from CVE-2025-68670 is that even in modern protocols and libraries, careful consideration of character encoding conversions is paramount. The UTF-16 to UTF-8 transformation is a well-known area where byte lengths can dramatically increase for certain characters. Ignoring these expansion ratios, or failing to perform strong bounds checking on the output after conversion, opens the door to classic buffer overflow or write-out-of-bounds scenarios. It’s a stark reminder that complexity, while necessary, can also be a breeding ground for subtle bugs.
The implications are significant for any system relying on xrdp, especially those where untrusted clients might connect. An attacker could potentially craft a specially-designed username or domain name string, leading to a write past the end of allocated buffers. This memory corruption can then be use to overwrite critical program data, gain control of the instruction pointer, and execute arbitrary code on the server. This is the textbook definition of remote code execution.
Is your xrdp installation vulnerable?
The good news is that the vulnerability is patched. The key is ensuring your xrdp installation is up-to-date. As mentioned, versions 0.10.5, 0.10.4.1, and 0.9.27 now include the fix. If you’re running an older, unpatched version, you are at risk.
Regularly checking for and applying updates to your remote desktop infrastructure isn’t just good practice; it’s a non-negotiable security requirement. For system administrators, this means prioritizing xrdp updates as you would any other critical server component.
🧬 Related Insights
- Read more: EvilTokens: Phishing’s Drag-and-Drop Nightmare for Microsoft Logins
- Read more: Security’s Wild Week: Fake Jobs, AI Chaos, and Supply Chain Scares
Frequently Asked Questions
What does xrdp do? xrdp is an open-source server that allows RDP clients to connect to Linux machines, providing a graphical remote desktop experience.
Can I exploit CVE-2025-68670 if I’m not using Kaspersky USB Redirector? Yes, the vulnerability exists within xrdp itself and is not dependent on the use of specific third-party modules like Kaspersky USB Redirector.
How do I check my xrdp version?
You can typically check your xrdp version by running xrdp -v or by examining the package manager information on your Linux distribution (e.g., dpkg -l xrdp on Debian/Ubuntu, rpm -qa | grep xrdp on Red Hat/CentOS).
