CVE-2025-68670 — xrdp Stack Buffer Overflow → Remote Code Execution
CVE ID: CVE-2025-68670
Severity: Critical
CVSS v3.1 (Base Score): 9.1
Exploitability: High if the service is reachable
Exploit Public Availability: No confirmed public exploit code at time of writing
Affected software: xrdp versions prior to 0.10.5
Fixed in release: xrdp version 0.10.5
Official patch/upgrade link: Link provided below
Overview
xrdp is a server that provides remote desktop access using the Remote Desktop Protocol (RDP) on Linux and Unix systems. Normally you install it to allow remote GUI login like you would on Windows.
In CVE-2025-68670, there was a programming flaw in the part of xrdp that reads incoming connection data — specifically, a string that represents the “domain” name sent by a connecting client. The code didn’t verify how long that string could be before copying it into a limited area in memory. Because of this missing safety check, an attacker who sends an oversized value in that field can cause the program to overwrite important data on the stack.
Simply put, the extra bytes spill over past the buffer into the stack frame. That corrupted stack can include the saved return address — which means an attacker can redirect where the program goes next. With careful control over that corruption and memory layout, code supplied by the attacker can be run inside the xrdp process. This can lead to remote code execution before any authentication takes place.
This is seriously bad: a remote attacker with no credentials can deliver a specially crafted connection and potentially take over the server or run arbitrary software.
Why It’s Critical
There are a few key reasons this gets a Critical severity rating:
- The flaw is remote, so there’s no need for physical access.
- It can be triggered before user authentication, meaning an attacker doesn’t need a valid login.
- It targets a network service that is commonly exposed to internal networks or even the internet.
- Successful exploitation can lead to full system compromise.
It is fundamentally a classic stack buffer overflow — which historically is one of the most dangerous types of software bugs because of the control it can give to attackers.
How Exploitation Could Work
To understand how an exploit would work — without going into harmful specifics — imagine the following:
- An attacker connects to the xrdp server’s listening port (usually TCP 3389).
- During the initial handshake, the attacker sends a crafted domain string that is far longer than what the vulnerable code expects.
- When xrdp parses that handshake, it blindly copies the oversized data into a fixed-size buffer on the stack.
- The buffer overflow overwrites the saved return address and perhaps other parts of the stack.
- If the attacker has knowledge of memory layout and protections on the system, they can direct execution to code they control — often shellcode embedded in the same malformed data.
Whether attackers succeed depends on several runtime protections like stack canaries, Address Space Layout Randomization (ASLR), and executable memory protections. These can make exploitation harder but not necessarily impossible, especially if other vulnerabilities or misconfigurations exist.
Although no public proof-of-concept code is confirmed at this time, the nature of the flaw means that once such code is released, automated scanning and exploitation attempts could spread quickly.
What to Do Right Now — Urgent Actions
- Apply the official patch or upgrade to xrdp 0.10.5 immediately.
Official patch/upgrade link:
➤ https://github.com/neutrinolabs/xrdp/releases/tag/v0.10.5 - If you cannot patch immediately:
- Restrict access to the RDP port (TCP 3389) with firewalls or network controls.
- Only allow RDP connections from trusted networks or via a VPN.
- Monitor logs continuously for signs of unexpected crashes or malformed session attempts.
How to Detect Attempts or Exploitation
Since there is no confirmed public exploit code yet, detection focuses on heuristics — unusual activity that could suggest someone is trying to trigger the overflow or scanning for it.
Logs to Monitor
xrdp Logs
Check the xrdp logs — typically found in /var/log/ — for any of the following:
- Frequent connection errors
- Unexpected descriptive error messages
- Crashes or segmentation faults shortly after a new connection is received
System Logs
Monitor system-level logs (e.g., syslog or journalctl) for:
- Reports of xrdp crashing repeatedly
- “bad access” or memory violation messages
- Unexpected core dump file creation
Network Traffic
Watch network traffic to the RDP port for:
- Unusually large or malformed handshake payloads
- Repeated connection attempts from the same source
- Patterns that don’t resemble normal RDP clients
Suricata Rules — Detecting Suspicious Activity
Below are example Suricata IDS rules you can use to catch potentially malicious activity related to this flaw.
These are heuristic in nature. They do not match a specific exploit byte sequence (no exploit payload is publicly known), but they will alert on suspicious session behavior that may indicate scanning or attempted exploitation.
1) Detect Oversized Domain Fields in Handshake
This rule looks for unusually large RDP handshake messages that are anomalous compared to a normal client:
alert tcp any any -> any 3389 (msg:"XRDP - Suspicious oversized handshake field"; flow:established,to_server; app-layer-proto:rdp; detection_filter:track by_src, count 5, seconds 30; threshold:type both, track by_src, count 3, seconds 60; sid:1000001; rev:1; priority:2;)
Explanation:
This targets the RDP handshake phase and flags if a number of unusually large packets are seen in a short timeframe. This doesn’t require specific content knowledge — it simply monitors for unexpected packet behavior.
2) Detect Possible xrdp Crashes
This rule triggers when a crash or unexpected disconnect happens shortly after connection:
alert tcp any any -> any 3389 (msg:"XRDP - Potential Crash or Disconnect"; flow:established,to_server; flags: R; threshold:type limit, track by_src, count 5, seconds 300; sid:1000002; rev:1; priority:3;)
Explanation:
This rule watches for TCP resets or abrupt session terminations that might be the result of xrdp crashing under bad input.
3) Detect Scanning Activity
This rule triggers on rapid repeat attempts to connect to RDP:
alert tcp any any -> any 3389 (msg:"XRDP - Possible brute/scan activity"; flow:to_server,established; threshold: type both, track by_src, count 10, seconds 60; sid:1000003; rev:1; priority:3;)
Explanation:
Rapid repetition of connection attempts may be scanning for vulnerable hosts. This isn’t specific to this CVE but is useful as a general defense layer.
Signs of Exploitation You Might See
Even without PoC code, the following patterns should be treated as high risk:
- xrdp crashing immediately on connection from certain IP ranges
- Core dumps attributed to xrdp
- Unexplained process creation by xrdp
- Unusual network connections or new services starting after an xrdp connection
If any of these are present, isolate the host and treat it as compromised until proven otherwise.
Final Takeaway
- Patch xrdp immediately using the official release that fixes this:
➤ https://github.com/neutrinolabs/xrdp/releases/tag/v0.10.5 - Apply network restrictions if patching is delayed.
- Use IDS rules to watch for anomalous RDP traffic.
- Monitor logs for crashes and unusual behavior.
- Treat any sign of exploitation seriously and investigate promptly.
