CVE-2026-55655

What it actually does

This vulnerability affects OpenSSH client-side X11 forwarding on Linux systems. When X11 forwarding is enabled and OpenSSH uses a local UNIX-domain X socket, a local unprivileged user can race or pre-bind the preferred abstract X socket name before the SSH client creates it. If successful, X11 forwarding traffic intended for the legitimate SSH client can be redirected through an attacker-controlled local socket. This can expose forwarded X11 session data such as window contents, clipboard-like interactions, keystrokes, and other GUI input/output, and may permit limited manipulation of the forwarded graphical session. Exploitation requires local access to the client host, user interaction through use of SSH X11 forwarding, and favorable timing or socket-name prediction conditions.

Why it matters to the business

The main business risk is local compromise of sensitive information handled through remote graphical applications, such as credentials typed into X11 windows, displayed documents, administrative consoles, or application data. The vulnerability is not remotely exploitable by itself and has a low EPSS score with no known KEV listing or public exploit maturity reported, but it matters on shared Linux workstations, jump hosts, developer systems, research environments, and administrative desktops where multiple local users may coexist and X11 forwarding is still used. Successful exploitation could undermine confidentiality of privileged remote sessions and create a path for further account or data compromise.

How an attack unfolds

An attacker first needs an unprivileged local account or code execution on the same Linux client host as a user who initiates SSH sessions with X11 forwarding enabled, for example using ssh -X or ssh -Y. The attacker anticipates or monitors for X11 forwarding activity and pre-binds the abstract UNIX-domain socket name that OpenSSH prefers for the forwarded X display. When the legitimate user starts an SSH connection with X11 forwarding, OpenSSH may connect forwarded X11 traffic to the attacker-controlled socket instead of a socket exclusively controlled by the client. The attacker can then observe X11 protocol traffic, potentially viewing application output, capturing sensitive input, and in some cases injecting or manipulating X11 events within the forwarded session. The attack is constrained to the local client host and depends on the victim using X11 forwarding during the attack window.

How to fix it

Upgrade OpenSSH packages from the operating system or vendor repository as soon as a fixed build is available for the affected distribution. No exact fixed versions were provided in the input, so use vendor advisories for OpenSSH and Red Hat Enterprise Linux to identify the corrected package versions. Where immediate patching is not possible, reduce exposure by disabling X11 forwarding unless explicitly required. On clients and managed SSH configurations, set ForwardX11 no and ForwardX11Trusted no by default. On SSH servers, consider setting X11Forwarding no where GUI forwarding is not a business requirement. Prefer modern alternatives that do not expose X11 forwarding semantics, such as remote desktop gateways, browser-based admin consoles, or isolated virtual desktops. On shared Linux hosts, restrict local shell access, separate administrative users from untrusted users, and avoid using X11 forwarding from multi-user systems.

How to confirm the fix worked

Confirm remediation by checking the installed OpenSSH client package version against the vendor-fixed version for the operating system. Review /etc/ssh/ssh_config, included ssh_config.d files, user ~/.ssh/config files, and command-line usage patterns to verify X11 forwarding is disabled by default unless required. Test that new SSH sessions do not set a DISPLAY value for forwarded X11 when X11 forwarding is not intended. On Linux clients where X11 forwarding remains enabled, inspect active UNIX-domain sockets with tools such as ss -xap or lsof -U and verify that X11 forwarding sockets are owned by the expected SSH client process and user. In shared environments, validate that unprivileged users cannot predictably pre-bind or interfere with sockets used by other users' forwarded sessions.

Typical attack path

1. Obtain an unprivileged local account or local code execution on a Linux system used as an SSH client.
2. Identify that users on the host use OpenSSH X11 forwarding, such as ssh -X, ssh -Y, ForwardX11, or ForwardX11Trusted.
3. Predict or discover the abstract UNIX-domain X socket name OpenSSH is likely to use for a forwarded display.
4. Pre-bind the preferred abstract X socket name before the victim's SSH client creates its socket.
5. Wait for the victim to initiate an SSH session with X11 forwarding enabled.
6. Receive or proxy forwarded X11 traffic through the attacker-controlled socket.
7. Inspect sensitive X11 data such as window contents and user input, and potentially inject limited X11 events into the forwarded session.

How to detect it

Look for evidence that X11 forwarding was used on Linux client hosts where untrusted local users or processes were present. Useful sources include endpoint process telemetry, shell history, auditd execve logs, EDR process events, SSH client debug logs if collected, syslog/auth logs where SSH client invocations or PAM session context are captured, and UNIX-domain socket inventories from live response. Hunt for ssh processes launched with -X or -Y, SSH client configuration enabling ForwardX11 or ForwardX11Trusted, unexpected local processes listening on abstract UNIX-domain sockets resembling X11 display sockets, and socket ownership mismatches where a non-SSH process owns a socket used for a forwarded display. Because exploitation occurs locally and may not generate network indicators, absence of remote network alerts does not rule it out. If suspicious activity is found, correlate the time window with remote GUI application use and investigate whether sensitive credentials, administrative actions, or displayed data may have been exposed.

• ssh -X
• ssh -Y
• ForwardX11 yes
• ForwardX11Trusted yes
• X11Forwarding yes
• /etc/ssh/ssh_config
• /etc/ssh/ssh_config.d/
• ~/.ssh/config
• DISPLAY=localhost:
• DISPLAY=127.0.0.1:
• Requesting X11 forwarding
• Allocated local X11 display
• connect /tmp/.X11-unix/X
• /tmp/.X11-unix/
• unix @/tmp/.X11-unix/X
• ss -xap
• lsof -U

What your security team should do

• Prioritize patching OpenSSH on shared Linux workstations, bastion-like client hosts, developer systems, and administrative desktops where local users are not fully trusted.
• Disable X11 forwarding by default across managed SSH client and server configurations unless there is a documented operational need.
• Inventory use of ssh -X, ssh -Y, ForwardX11, and ForwardX11Trusted through endpoint telemetry, shell history where appropriate, configuration management, and SSH configuration scans.
• Educate administrators and developers not to use X11 forwarding from shared or untrusted Linux hosts, especially for privileged remote sessions.
• Monitor local multi-user systems for suspicious UNIX-domain socket listeners associated with X11 display names that are not owned by legitimate SSH client processes.
• Track vendor advisories for OpenSSH and Red Hat Enterprise Linux and deploy the first available fixed packages, since no fixed versions were supplied in the input.
• Treat suspected exploitation as a potential credential and data exposure event for any remote GUI applications used during the affected session.