CVE-2026-35388

What it actually does

OpenSSH clients before 10.3 fail to require the expected connection-multiplexing confirmation when a multiplexed session is opened in proxy mode. In affected configurations, a local attacker who can reach a user's SSH multiplex control socket may be able to create a new proxy-style channel over that user's already-authenticated SSH master connection without the confirmation prompt that the user expected. The impact is limited: it does not expose private keys or existing session contents, but it can allow unauthorized use of the authenticated SSH connection for limited traffic proxying or remote actions reachable through that connection.

Why it matters to the business

The practical risk is low but relevant for workstations, jump hosts, developer systems, and automation hosts that use OpenSSH connection multiplexing. An attacker with local access and the right timing/configuration could piggyback on a legitimate SSH connection and perform limited actions as the connected user, potentially causing unauthorized changes on remote systems or misuse of trusted access paths. The issue is not listed in CISA KEV, has no known mature exploit, and has a very low EPSS score with no recent upward trend, so it should be remediated through normal patch cycles unless high-value systems rely heavily on SSH multiplexing.

How an attack unfolds

An attacker first needs local access to the same system where a victim uses an affected OpenSSH client and must identify an active multiplexing control socket created by the victim's SSH master connection. The attack is most viable where ControlMaster/ControlPath/ControlPersist are enabled and where socket permissions or placement allow another local process to reach the control socket. The victim must have an established authenticated SSH master connection that would normally require confirmation before allowing additional multiplexed use. The attacker then connects to the control socket and requests a proxy-mode multiplexed session, such as a channel that carries traffic to a remote host or port through the existing SSH connection. Because affected OpenSSH versions omit the confirmation step for this proxy-mode case, the proxy channel may be created without the user's approval. The attacker can then send traffic through the victim's authenticated SSH connection, potentially accessing remote services or performing limited actions under the context of the existing SSH authentication.

How to fix it

Upgrade OpenSSH to version 10.3 or later when available from the operating system or vendor package repository. Where direct upstream versions are not used, apply the vendor security update that backports the fix for this issue. As interim mitigation, disable or restrict SSH connection multiplexing for sensitive workflows by avoiding ControlMaster, ControlPersist, and shared ControlPath settings; store multiplex control sockets only in user-private directories with restrictive permissions; avoid world-writable locations such as /tmp unless the path uses safe permissions and unpredictable names; and terminate stale master connections with `ssh -O exit` or by ending the relevant SSH master process. On multi-user systems, review filesystem permissions so other local users cannot access another user's SSH control sockets.

How to confirm the fix worked

Confirm the installed OpenSSH client version is 10.3 or later, or verify the operating system vendor advisory states the package includes the backported fix. Use `ssh -V` to identify the OpenSSH client version, then compare it against vendor package metadata. Review SSH client configuration from `/etc/ssh/ssh_config`, included config files, and user `~/.ssh/config` files for ControlMaster, ControlPath, and ControlPersist usage. Confirm multiplex control sockets are created only in directories writable and searchable by the owning user. For mitigation validation, attempt to connect to a user's multiplex control socket from another local account; access should fail due to filesystem permissions or absence of a shared socket.

Typical attack path

1. Gain local code execution or local interactive access on a system where a victim uses the OpenSSH client.
2. Discover active OpenSSH multiplex control sockets, commonly defined by ControlPath and created by ControlMaster/ControlPersist.
3. Identify a socket associated with a live authenticated SSH master connection to a useful remote destination.
4. Connect to the multiplex control socket and request a proxy-mode session through the existing master connection.
5. Use the unauthorized proxy channel to send traffic to remote systems or services reachable through the victim's SSH connection.
6. Perform limited unauthorized actions or pivoting that benefit from the victim's established SSH authentication or network reachability.

How to detect it

Look for evidence that local processes accessed SSH multiplex control sockets and opened proxy-style channels through existing master connections. Useful sources include endpoint process telemetry, shell history, auditd or equivalent file/socket access logs, EDR command-line records, SSH client debug logs if enabled, and remote SSH server logs. On endpoints, search for commands that combine a multiplex control socket with proxying, such as `ssh -S <socket> -W <host>:<port>`, or tooling such as `socat`, `nc`, or custom scripts connecting to SSH ControlPath sockets. Review access to ControlPath locations defined in `/etc/ssh/ssh_config`, included SSH config files, and `~/.ssh/config`. On remote SSH servers, default logs may only show the original master connection, not each multiplexed channel; with verbose logging, look for unexpected `direct-tcpip` channels, proxy activity, or remote access that occurs after the original login without a corresponding new authentication event. Because this issue has no known public exploit maturity and no KEV listing, detection should focus on anomalous local socket access and unexpected use of existing SSH sessions rather than known malware artifacts.

• ssh -S
• -W
• ControlMaster
• ControlPath
• ControlPersist
• direct-tcpip
• mux_client_proxy
• proxy-mode
• ~/.ssh/config
• /etc/ssh/ssh_config
• /tmp/ssh_mux_
• /tmp/ssh-
• ~/.ssh/controlmasters/
• ssh -O check
• ssh -O proxy

What your security team should do

• Inventory systems with OpenSSH clients before 10.3, prioritizing developer workstations, bastion hosts, jump hosts, CI/CD runners, and shared Unix/Linux systems.
• Patch OpenSSH through normal change windows, or faster for multi-user systems where SSH multiplexing is enabled and local untrusted users are present.
• Review enterprise SSH client configuration for ControlMaster, ControlPath, and ControlPersist, and standardize safe ControlPath locations under user-private directories.
• Hunt for unusual local processes invoking SSH multiplex sockets with proxy options, especially combinations of `ssh -S` and `-W`.
• Enable or tune endpoint telemetry/audit rules to monitor access to SSH control sockets on shared systems.
• Educate administrators and developers not to place SSH multiplex control sockets in shared directories with weak permissions.
• Terminate long-lived or stale SSH master sessions on sensitive hosts until patched.