Insufficient Xvnc authentication allows cross-user desktop access in neutrinolabs xrdp

xrdp is an open source RDP server. In versions 0.10.6 and prior, when an authenticated user session is initialized using the Xvnc backend over UNIX domain sockets, the Xvnc process is launched with insufficient authentication mechanisms. A local authenticated attacker could exploit this vulnerability to bypass intended session isolation, allowing them to unauthorizedly view or control the active desktop sessions of other users on the same system. Users using other backends, such as xorgxrdp or Xvnc over TCP sockets, are not affected. This issue has been fixed in version 0.10.6.1.

• The vendor advisory identifies neutrinolabs xrdp as affected in >= 0.10.3, <= 0.10.6 when sessions are initialized with the Xvnc backend over UNIX domain sockets.
• The normalized affected data marks xrdp with the range < 0.10.6.1. The vendor's detailed affected range does not establish the status of versions before 0.10.3, so earlier versions should not automatically be treated as affected based on the available evidence.
• The issue is fixed in 0.10.6.1.
• Deployments using other backends, such as xorgxrdp, or using Xvnc over TCP sockets are identified as unaffected.

neutrinolabs xrdp initializes an authenticated user session with the Xvnc backend over UNIX domain sockets, but launches the Xvnc process with insufficient authentication mechanisms. The flaw falls within missing authentication for a critical function and improper authentication, represented by CWE-306 and CWE-287. The attacker must have local access and an authenticated account capable of initializing a session through the affected backend. By taking advantage of Xvnc's insufficient authentication state, the attacker can bypass intended session isolation and view or control another user's active desktop session on the same system. The available evidence does not identify a specific payload, input parameter, file path, or launch argument controlled by the attacker. The exact missing authentication mechanism and the implementation details of the launch sequence are not documented in the sources reviewed.

• Reachability: The described attack is local and is not remotely reachable over the network.
• Authentication: The scenario requires a local authenticated user who can initialize a session using Xvnc over UNIX domain sockets.
• Interaction: No victim interaction is described as necessary.
• Status: The supplied record does not identify a public exploit; known_exploited is null, so the real-world exploitation status is not fully established.

The flaw allows a local authenticated user to gain unauthorized access to another user's active desktop session on the same system. The technical result may include reading displayed data and performing actions through the accessed session, so the primary effects are loss of confidentiality and integrity. No remote, cross-host, or specific denial-of-service behavior is established. Exploitation also depends on the session using the Xvnc backend over UNIX domain sockets; the explicitly excluded backends and transports are outside the documented scope.

The primary risk is loss of session isolation on shared systems where multiple users have active desktop sessions.

• An attacker may view content displayed in another user's desktop session, increasing the risk of exposure of data open on that desktop.
• An attacker may control another user's session and perform unauthorized actions within that session's available permissions.
• The issue can affect the confidentiality and integrity of user activity on the same server. The available material does not describe a specific service outage scenario.
• The risk is limited to systems using the affected backend and transport. No evidence establishes remote access or cross-host impact.

1. Upgrade xrdp to exactly 0.10.6.1, the release identified by the vendor advisory as containing the fix.
2. Verify that every deployed instance, image, and package actually runs the fixed release rather than updating only one host or manifest.
3. After upgrading, review the backend and transport used by sessions to confirm that affected deployments no longer initialize Xvnc over UNIX domain sockets on a vulnerable release.
4. The available material does not provide a separate workaround. If an upgrade cannot be completed, temporarily avoiding Xvnc over UNIX domain sockets and using another backend or transport where operationally suitable is a reasoned risk-reduction measure, not a vendor-confirmed fix.

1. Inventory every xrdp deployment and determine the version actually running, not only the version available from a package repository.
2. Review session configuration to identify deployments that use the Xvnc backend over UNIX domain sockets.
3. Separately classify deployments using xorgxrdp or Xvnc over TCP sockets, because the advisory identifies those configurations as unaffected.
4. On shared systems, check whether active desktop sessions can be initialized through the affected backend and transport.
5. The available material does not define a specific IOC or log signature. Generic monitoring is only a precaution, and the absence of suspicious events does not demonstrate that a system is safe.