A flaw was found in OpenSSH sftp. During a copy, a server-supplied empty directory entry, a path made only of slashes, or a ".." basename is used as the local destination. The write runs as the user who started sftp, and the server must be one that user chose to copy from. This is an incomplete fix for CVE-2026-59995. That fix only stopped interactiveloop from building a command string. It does not rewrite these destination names. Reserve a new CVE. Do not reuse CVE-2026-59995.

OpenSSH through 9.6, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mmanswerauthpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges.

https://arxiv.org/abs/2309.02545 https://github.com/openssh/openssh-portable/blob/8241b9c0529228b4b86d88b1a6076fb9f97e4a99/auth-passwd.c#L77 https://github.com/openssh/openssh-portable/blob/8241b9c0529228b4b86d88b1a6076fb9f97e4a99/monitor.c#L878

A flaw was found in OpenSSH. Outbound compression used deflateInit with the default level, so every channel on a connection shared one LZ77 search buffer. A peer who can write on one channel can recover plaintext from another channel by observing ciphertext lengths, as described in "Crossing the Streams" (Fabian Bäumer and Marcus Brinkmann, 2026). The fix switches outbound compression to ZHUFFMANONLY, which removes LZ77 matching and lowers the compression ratio. The RHEL maintainer will take that fix. The OpenSSH client does not offer compression by default. The server zlib default is delayed compression, which applies only if the client offers it.

A flaw was found in OpenSSH ssh. sshvalidruser did not reject '$' or a backslash that is not at the end of a username entered on the command line. Those characters still expand through %u in ProxyCommand or Match exec. Usernames written in the configuration file are not subject to this check. CVE-2026-35386 is already backported and rejects a different set of shell metacharacters, plus a trailing backslash. Hostnames in that fix already reject '$' and '\'. Usernames do not. This is a new CVE on top of CVE-2026-35386.

A flaw was found in OpenSSH. After compression is negotiated, a compressed payload can expand past the maximum supported packet size because the inflate loop does not stop at that limit. Memory use grows in the process handling that connection.

In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.

In ssh in OpenSSH before 10.6, a $ or \ character can occur in a command-line username, leading to injection.

A flaw was found in OpenSSH sshd when GSSAPIAuthentication is enabled. A partial GSSAPI exchange left gssapiclient, including an exported name and credential, for a later authentication attempt on the same connection. sshgssapistorecreds stored delegated credentials even when sshgssapiuserok had not succeeded. The RHEL maintainer confirmed that this does not authorize a later login. The impact is storage of a delegated credential that userok did not accept. RHEL ships GSSAPIAuthentication yes. On RHEL 10, GSSAPIDelegateCredentials defaults to yes, and storecreds returns early only when that switch is off. This is not CVE-2026-60000 (MaxAuthTries and GSSAPI) and not CVE-2026-3497 (GSSAPI key exchange).

A flaw was found in OpenSSH. uncompressbuffer could keep growing the output buffer inside the inflate loop until it passed the maximum packet size. The fix returns SSHERRINVALIDFORMAT once the buffer reaches PACKETMAXSIZE. This applies only after compression has been negotiated. The extra memory stays in that connection's process. This is not a demonstrated memory-corruption flaw, and it is a different bug and reporter from the LZ77 dictionary leak.

A flaw was found in OpenSSH. Outbound compression used deflateInit with the default level, so every channel on a connection shared one LZ77 search buffer. A peer who can write on one channel can recover plaintext from another channel by observing ciphertext lengths, as described in "Crossing the Streams" (Fabian Bäumer and Marcus Brinkmann, 2026). The fix switches outbound compression to ZHUFFMANONLY, which removes LZ77 matching and lowers the compression ratio. The RHEL maintainer will take that fix. The OpenSSH client does not offer compression by default. The server zlib default is delayed compression, which applies only if the client offers it.

A flaw was found in OpenSSH ssh. sshvalidruser did not reject '$' or a backslash that is not at the end of a username entered on the command line. Those characters still expand through %u in ProxyCommand or Match exec. Usernames written in the configuration file are not subject to this check. CVE-2026-35386 is already backported and rejects a different set of shell metacharacters, plus a trailing backslash. Hostnames in that fix already reject '$' and '\'. Usernames do not. This is a new CVE on top of CVE-2026-35386.

ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)

ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.

OpenSSH server (sshd) 9.1 introduced a double-free vulnerability during options.kexalgorithms handling. This is fixed in OpenSSH 9.2. The double free can be leveraged, by an unauthenticated remote attacker in the default configuration, to jump to any location in the sshd address space. One third-party report states "remote code execution is theoretically possible."

A flaw was found in OpenSSH. A local unprivileged attacker on a Linux client host can hijack client-side X11 forwarding connections. This is possible by pre-binding the preferred abstract X socket name when X11 forwarding is enabled and a local UNIX-domain X socket is used. A successful attack can compromise the confidentiality of forwarded X11 traffic, including sensitive window contents and input, and may allow some manipulation of the forwarded session.

In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.

In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.

In sshd in OpenSSH before 10.6, the restrict keyword (in authorizedkeys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.

AIONLYREPORT package: openssh-9.9p1-22.el102 ------ Summary: Local MITM of X11 forwarding via preferred Linux abstract UNIX socket connection: a local unprivileged process on the Linux client host can hijack the client-side X11 forwarding connection by pre-binding the preferred abstract X socket name. Requirements to exploit: An attacker needs local unprivileged code execution on the Linux host running the OpenSSH client, client-side X11 forwarding enabled (-X, -Y, or equivalent configuration), a local DISPLAY that resolves to a UNIX-domain X socket such as :0 or unix:0, and a forwarded X11 connection to be opened while the attacker has pre-bound the matching abstract socket name. Component affected: openssh-9.9p1-22.el102, client-side X11 forwarding code in openssh-9.9p1/channels.c (connectlocalxsocket(), x11openhelper()). Version affected: openssh-9.9p1-22.el102; reachable on Linux in the client-side X11 forwarding path when X11 forwarding is enabled and DISPLAY resolves to a local UNIX-domain X socket Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N - 5.3 (MEDIUM) AV:L - The attacker must already have local code execution on the Linux system running the OpenSSH client. AC:H - Exploitation depends on a feature-specific client configuration, successful pre-binding of the matching abstract X11 socket, and a forwarded X11 connection actually being opened. PR:L - An unprivileged local user account or equivalent local process execution is sufficient. UI:R - A user must enable X11 forwarding and the session must trigger a forwarded X11 connection. S:U - The impact stays within the client-side OpenSSH/X11 forwarding security scope. C:H - A successful hijack can expose forwarded X11 traffic, including sensitive window contents and input; when real xauth data is available, the saved X11 authentication data may also be substituted into the hijacked stream. I:L - The attacker can influence the X11 protocol stream presented to the forwarded application, but the demonstrated effect is narrower than general host compromise. A:N - The issue does not require a direct availability impact to succeed. Impact: Moderate. A successful attack can compromise the confidentiality of forwarded X11 traffic and allow some integrity impact on the forwarded session, but exploitation is limited to a local attacker on the client host and depends on the non-default, feature-specific condition that X11 forwarding is enabled and used. Under Red Hat’s criteria, this is better classified as Moderate than Important because it is real but not easily exploitable in typical deployments. Embargo: no Reason: This is a local, configuration-dependent client-side issue with straightforward mitigation by disabling X11 forwarding where it is not required, and it does not present an easily exploitable remote compromise path. Acknowledgement: Aisle Research Vulnerability Details: This issue is in the OpenSSH client’s Linux X11 forwarding path. When the client receives an X11 open request, the call path reaches x11connectdisplay(), which parses DISPLAY and, for local UNIX-domain displays such as :0 or unix:0, calls connectlocalxsocket(). In the vulnerable path, Linux tries the abstract UNIX socket name before the filesystem socket: c len = snprintf(buf + 1, sizeof (buf) - 1, PATHUNIXX, dnr); #ifdef linux / try abstract socket first / buf[0] = '\0'; if ((ret = connectlocalxsocketpath(buf, len + 1)) >= 0) return ret; #endif if ((ret = connectlocalxsocketpath(buf + 1, len)) >= 0) return ret; PATHUNIXX resolves to /tmp/.X11-unix/X%u, so on Linux the first attempted endpoint is the abstract socket name \0/tmp/.X11-unix/X<display>. Because Linux abstract UNIX sockets are not mediated by filesystem permissions, an unprivileged local process can pre-bind that name and receive the forwarded X11 connection before the legitimate filesystem socket. The connection helper performs a direct connect() and does not verify peer credentials or ownership after the connection succeeds. OpenSSH’s X11 spoofing logic validates the fake cookie received from the remote side, but it does not authenticate the local X11 endpoint. After the fake cookie check passes, the client replaces it with the saved X11 authentication data: c if (datalen != sc->x11fakedatalen || timingsafebcmp(ucp + 12 + ((protolen + 3) & ~3), sc->x11fakedata, sc->x11fakedatalen) != 0) { debug2("X11 auth data does not match fake data."); return -1; } ... memcpy(ucp + 12 + ((protolen + 3) & ~3), sc->x11saveddata, sc->x11saveddatalen); As a result, an attacker-controlled abstract socket can receive the forwarded X11 session first. Where real xauth data was obtained, the rewritten first packet will contain the saved X11 authentication data. If xauth data is unavailable, OpenSSH can fall back to generated fake data, which reduces credential-leak impact but does not prevent the connection hijack or interception of the forwarded X11 stream. The available evidence supports interception and limited manipulation of forwarded X11 sessions, not arbitrary code execution or privilege escalation in the client itself. Steps to reproduce: 1. On a Linux system running the OpenSSH client, confirm the local display uses a UNIX-domain socket such as :0 or unix:0. 2. Before opening a forwarded X11 connection, start a local unprivileged listener bound to the matching abstract socket name. For display :0: python import socket s = socket.socket(socket.AFUNIX, socket.SOCKSTREAM) s.bind("\0/tmp/.X11-unix/X0") s.listen(1) c, = s.accept() print("accepted; first bytes:", c.recv(64).hex()) 3. In another terminal, start an SSH session with X11 forwarding enabled: bash ssh -X user@remote 4. From the remote shell, trigger an X11 application so that the client opens the forwarded X11 channel, for example: bash xclock 5. Observe that the attacker listener accepts the connection and receives the initial X11 bytes before the legitimate filesystem socket /tmp/.X11-unix/X0 is used. 6. Optional confirmation: bash strace -f -e connect ssh -X user@remote Expected result: tracing shows a successful AFUNIX connect to the abstract socket name \0/tmp/.X11-unix/X0 before any successful connect to /tmp/.X11-unix/X0. Mitigation: Disable X11 forwarding on affected clients when it is not required, for example by avoiding -X/-Y and using ForwardX11 no. On shared Linux systems where untrusted local users or processes may be present, avoid relying on client-side X11 forwarding until a fix that prefers the filesystem X socket has been applied. Proposed Fix: Prefer the filesystem X11 socket first, and retain Linux abstract sockets only as a compatibility fallback. diff diff --git a/openssh-9.9p1/channels.c b/openssh-9.9p1/channels.c @@ static int connectlocalxsocket(uint dnr) len = snprintf(buf + 1, sizeof (buf) - 1, PATHUNIXX, dnr); + / Prefer filesystem socket (permission/ownership mediated) / + if ((ret = connectlocalxsocketpath(buf + 1, len)) >= 0) + return ret; #ifdef linux - / try abstract socket first / + / Abstract socket fallback for compatibility / buf[0] = '\0'; if ((ret = connectlocalxsocketpath(buf, len + 1)) >= 0) return ret; #endif - if ((ret = connectlocalxsocketpath(buf + 1, len)) >= 0) - return ret; error("connect %.100s: %.100s", buf + 1, strerror(errno)); return -1; ------ This report was generated using AI technology. Always review AI-generated content prior to use

On affected platforms, if SSH session multiplexing was configured on the client side, SSH sessions (e.g, scp, sftp) multiplexed onto the same channel could perform file-system operations after a configured session timeout expired

In sshd in OpenSSH through 10.6, in certain environments such as QNX 6 and SCO OpenServer 5, sshd-session can unexpectedly have root privileges. This is related to the GatewayPorts and StreamLocalForwarding configuration options, and lack of support for file-descriptor passing and unprivileged allocation of PTY devices.

In sshd in OpenSSH through 10.6, use of the macOS 27 (or later) SDK has the side effect of loss of sandboxing, which is potentially unexpected.

OpenSSH 10.6 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support.

Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance. While many AI reports are determined not to have security impact when considered in the context of a realistic threat model, we very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes.

We have seen a number of cases where a security bug identified by AI tools is subsequently independently discovered by a different researcher. This suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too. Given this, the OpenSSH team will, for now, be making more frequent releases to get bugfixes into users' hands more quickly rather than batching them until the next planned release.

Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html

Future deprecation notice -------------------------

scp(1): begin deprecating the -R flag, which is used to perform a remote-to-remote copy by executing scp on a remote host. This option is a fragile optimisation that is difficult to use because it requires credentials on the remote host. It also creates security risks if the shell quoting rules on the remote system where the copy is performed differ from the client's expectations.

From OpenSSH 10.6, this option will continue to work but will cause a deprecation warning to be emitted to standard error. In a future release, the option will be ignored and will leave in place the default remote-to-remote copy behaviour (copy via the host running scp).

sshd(8): support for platforms that do not allow file descriptor passing and that also require root privilege for PTY allocation will be removed in a future release. Affected platforms are known to include SCO OpenServer 5 and QNX 6 but may include other similarly old operating systems. This deprecation can be avoided if the user community for these platforms is able to assist us in building alternatives, such as avoiding the need for root in PTY allocation.

Potentially-incompatible changes --------------------------------

ssh(1), sshd(8): compression will be less effective as a result of the change noted below in the "Security" section

ssh(1): destination usernames entered on the commandline are now more stricly checked and will refuse usernames that include backslash and dollar symbols. Usernames that are specified by the "User" directive in configuration files are no subject to these restrictions. This motivation for this change is mentioned below in the "Security" section.

sshd(8): on platforms that do not support file descriptor passing and that require root for PTY allocation, the GatewayPorts and StreamLocalForwarding options are forcibly disabled. The motivation for this changes is discussed below in the "Security" section.

Changes since OpenSSH 10.5 ==========================

This release contains a number of security fixes, several new features and some small bugfixes.

Security ========

sftp(1): more strictly validate paths returned from the server to avoid some cases where a server could return paths that could manipulate a recursive copy operation into writing outside its target directory. Report and patch from Junghoon Cho.

sshd(8): when GSSAPIAuthentication is in use, only store GSSAPI credentials when authentication has succeeded. Avoids a situation where credentials from a failed GSSAPIAuthentication attempt may persist and be made inappropriately available if another authentication subsequently succeeds. Issue report and patch from Moritz Theile.

sshd(8): reset GSSAPIAuthentication before authentication, avoiding state from one authentication attempt being confused with that of a later attempt. Report and feedback from Moritz Theile.

sshd(8), ssh(1): disable LZ77 dictionary coder to mitigate the side-channel leaks described in "Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels" by Fabian Bäumer and Marcus Brinkmann, preprint https://arxiv.org/abs/2609.07709 (2026)

A chosen-plaintext attack method exists which makes use of dictionary-based compression to recover secrets from one channel by interacting with the SSH session's shared compression dictionary through another channel.

Attacker-controlled input can recognizably reflect into the total length of transmitted ciphertexts by virtue of LZ77 replacing repeated strings with back-references into the SSH session's encoder search buffer, which is shared across all channels. For this reason, the documentation already recommended against enabling compression for connections that share trusted and untrusted traffic.

This change will reduce the effectiveness of the Compression option. Users are encouraged to use application-level compression over the SSH protocol where possible, as this will typically be more effective and will be completely immune to this type of attack.

ssh(1): disallow '$' and '\' characters in usernames entered on the command-line to avoid usernames from untrusted sources yielding injection in shell context via ProxyCommand, Match exec, etc. Usernames specified via the configuration files are not subject this this control. Reported by SecBuddyF KeenLab Tencent (CodeBuddy Security)

We continue to recommend against directly exposing ssh(1) and other tools' command-lines to untrusted input. Mitigations such as this can not be absolute given the variety of shells and user configurations in use.

ssh-keygen(1): correct handling of Daylight Saving Time when converting dates. Previous handling could cause errors of up to +/- 1 hour (unless you are in the Antarctica/Troll timezone, where the error could be +/- 2 hours). These errors could result in creation of certificates with incorrect expiry times. bz4004; from Khush Patel

sshd(8), ssh(1): ensure that compressed payloads don't inflate past the maximum supported packet length. Reported by Oleh Konko.

sshd(8): fully honor the authorizedkeys "restrict" keyword, which was not being properly applied to tunnel forwarding (PermitTunnel, disabled by default). This is a separate problem to the one fixed in openssh-10.5.

sshd(8): correctly handle some options that accept "none". Some options, including AuthorizedPrincipalsFile, were documented as accepting "none" as a way to disable them; however, when overridden by an sshdconfig(5) Match keyword, this argument was being incorrectly interpreted as a literal file. With Chris Rohlf in collaboration with Claude and Anthropic Research

sshd(8): On OS X SDK >= 27, sandboxing is no longer supported as the API we depended upon has been removed and no obvious alternative provided.

sshd(8): on platforms that do not support file descriptor passing and that require root for PTY allocation, the post-authentication sshd-session process retains root privilege, whereas on other platforms this process runs with the privilege of the logged-in user. When sshd-session was run with elevated privlege, it could perform certain actions as root and circumvent controls that would normally have applied to the user, such as making unix domain socket connections or binding (via -R forwarding) to low- numbered TCP ports.

For this reason, this release disables the GatewayPorts and StreamLocalForwarding options and support for these (few) platforms will be removed in future if no alteratives to requiring privilege in the post-authentication process are found. Affected platforms include QNX 6, SCO OpenServer 5 and builds that were made with the --disable-fd-passing configure option.

This problem was reported separately by sn0x-sharma and by Dark River.

New features ------------

All: enable hybrid post-quantum ssh-mldsa44-ed25519 signature algorithm. Note that this no longer uses the "@openssh.com" vendor extension suffix that the previous experimental implementation used. Keys generated with the previous experimental support must be regenerated and/or removed.

sshd(8): Add the WarnWeakCrypto option to sshdconfig(5). This option was previously available for the client only. This option is enabled by default and will log when the client uses a key agreement scheme that is not post-quantum safe.

ssh-keygen(1), ssh-add(1): preserve user-verification (PIN or biometric) requirement for resident keys loaded from a FIDO token, by checking the credential's credProtect policy. GHPR701 from Savely Krasovsky

ssh(1): include local and remote version strings in the ~I connection information display.

ssh-add(1): add a -P flag to skip PIN entry for FIDO and PKCS#11 tokens that do not require it.

sftp(1): add '-p' flag for mkdir/lmkdir to create directories as required. This flag has similar ergonomics to mkdir(1), and previously-existing directories do not cause an error.

ssh-keygen(1): add a "hexdump" key export mode that dumps the SSH wire-formatted key blob in hex format. Useful when writing documentation, tests, etc. E.g. ssh-keygen -em hexdump -f /key

ssh(1), sshd(8): ChannelTimeout now accepts timeouts with fractional seconds.

sshd(8): allow specification of the location of $SSHAUTHSOCK used for agent forwarding using a new AgentSocketPath option. This supports both using a user-specific path, such as the default of a subdirectory of $HOME ("user:.ssh/agent"), and the previous approach of allowing agent forwarding sockets to be located in a shared directory (e.g. "shared:/tmp"). Sockets created in shared directories will be created inside a subdirectory with a randomised name. bz3860

ssh-agent(1): allow specification of agent socket directories using a -A flag. It accepts "user:" and "shared:" directory styles similar to the sshd AgentSocketPath option.

sshd(8): account for public key authentication "key ok" tests separately to auth attempts. Add a PubkeyOptions max-pk-ok:nnnn option to allow a number of PKOK tests (asking whether the server might accept a given public key) that do not count against MaxAuthTries, defaulting to 6 attempts. After these attempts are exhausted, further attempts count as failed authentications against MaxAuthTries. Practically, this allows more keys on disk or held in ssh-agent to be checked for use before the server disconnects.

ssh(1), sshd(8): extend the existing TCPKeepAlive option to also support setting keepalives on sockets created for forwarding connections. Previously this option controlled keepalives on the connection socket only. TCPKeepAlive "yes" or "transport" enables keepalives on the connection socket. "TCPKeepAlive all" additionally enables them for forwarding sockets. bz3921

Bugfixes --------

sshd(8), ssh(1): fix configuration matching on more Turkic languages which have disjoint dotted and dotless i/I characters, specifically Azerbaijani and Crimean Tatar. bz3991

ssh(1), sshd(8): don't attempt to set TCPNODELAY on non-IP/IPv6 sockets. Eliminates some noise in debug logs.

ssh(1): fix case for ssh -G option output; bz4005

ssh(1), sshd(8): Fix ChannelTimeout specificity; previously a more specific channel type (e.g. "session:shell") could clobber a user-specified ChannelTimeout if it was less specific (e.g. "session"). Also, in some cases, the debug messages were printing 0 instead of the effective timeout. bz3994

sftp(1): avoid NULL dereference crash in some circumstances when a server fails a stat/lstat operation. GHPR707

sshd(8): close a race condition where a SIGTERM/SIGQUIT would be ignored if it was received by the server while it was processing a SIGHUP restart request. bz3981

sshd(8), ssh(1): check key and CA signature types during key parsing against allowlists (PubkeyAcceptedAlgorithms, etc) as early as possible. This reduces the attack surface presented by disabled algorithms. Suggested by and with extensive feedback from Chris Rohlf in collaboration with Claude and Anthropic Research.

All: switch the fallback implementation of the ed25519 signature algorithm used when libcrypto is disabled from SUPERCOP ed25519 to libsodium. The libsodium implementation includes a number of strictness checks over the original reference implementation we have used to this point and a more ergonomic API.

ssh-add(1), ssh(1), ssh-keygen(1): fix spin on password entry when the program attempting to read a password was started in a background process group, with no TTY and with certain signals ignored. bz3995

scp(1): disallow nul byte in received scp -O filename. This was not reachable in normal operation. Reported by Chua Wei Xun.

ssh-keygen(1), ssh(1), sshd(8): implement a maximum number of KDF rounds that will be accepted when writing an OpenSSH-format private key or when loading one. This limit is set quite high (1M), but ensures that a service that is passed a bad key with a ridiculously high number of rounds will eventually complete parsing it.

ssh-keygen(1): bump the default number of KDF rounds from 24 to 32 (this is a linear increase, not like bcrypt(3) which is exponential).

ssh(1): make StreamLocalBindMask properly respect Host/Match blocks and make it first-match-wins as documented. bz4013

sshd(8): make StreamLocalBindMask properly first-match-wins.

Portability -----------

All: remove the NetBSD BROKENREADCOMPARISON workaround. This appears to be no longer required and caused pre-auth CPU spinning.

sshd(8): don't link sshd against libselinux when SELinux support is enabled (note: this library is still linked for the sshd-auth and sshd-session helper binaries).

sshd(8): allow madvise(..., MADVDONTNEEDLOCKED) in the seccomp sandbox; needed by GrapheneOS' hardened allocator. bz4001

sshd(8): restrict mremap(2) flags accepted by the seccomp sandbox. Only MREMAPMAYMOVE is now accepted as other flags may have some utility in attack chains. Reported by: Mohammad Hossein Abedini.

sshd(8): allow PAMServiceName in Match (regressed in 10.4). During the refactor of server option parsing, the ability to set PAMServiceName in Match blocks was accidentally disabled.

sshd(8): the --disable-fd-passing configure option has been removed.

Checksums: ==========

- SHA1 (openssh-10.6.tar.gz) = 096e9cd60cd08e0acacfe16b615144f8c0463da5 - SHA256 (openssh-10.6.tar.gz) = 0lP9h9/QH3k667vqbxKhkkusc3CN5iKUiDNI9fsR06A= - SHA1 (openssh-10.6p1.tar.gz) = e6a34f5625e20172b214c50ebd4e0dcb4fd18013 - SHA256 (openssh-10.6p1.tar.gz) = qdyVZd/+hkD2TYY80poyvEo9vewFZqf8RMXW7nZ9Xzk=

Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASEKEY.asc

Reporting Bugs: ===============

- Please read https://www.openssh.com/report.html Security bugs should be reported directly to openssh () openssh com

AIONLYREPORT package: openssh-10.2p1-10.1.hum1 ------ Summary: Heap out-of-bounds read in GSSAPI indicator cleanup: missing trailing NULL termination in the GSSAPI auth-indicators array allows sentinel-based consumers to read past the allocated pointer array and may trigger an invalid free during cleanup. Requirements to exploit: An attacker needs network access to SSH on openssh-10.2p1-10.1.hum1 built with GSSAPI support and deployed with GSSAPIAuthentication yes; in this tree that option defaults to disabled. The Kerberos environment must provide a ticket containing at least one authenticated auth-indicators value, and execution must then reach either the failed sshgssapiuserok() cleanup path or the GSSAPIIndicators matching path. Component affected: openssh-10.2p1-10.1.hum1, server-side GSSAPI authentication code in gss-serv.c (sshgssapigetindicators()), with sentinel-based consumption in gss-serv.c (sshgssapiuserok()) and gss-serv-krb5.c (sshgssapicheckindicators()) Version affected: openssh-10.2p1-10.1.hum1 when built with GSSAPI support; remote triggerability additionally requires GSSAPIAuthentication yes and a Kerberos deployment that supplies authenticated auth-indicators Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not yet established. CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L - 3.7 (LOW) AV:N - the vulnerable path is reachable through network SSH authentication traffic. AC:H - exploitation depends on a GSSAPI-enabled build, GSSAPIAuthentication yes, a Kerberos ticket carrying authenticated auth-indicators, and reaching a sentinel-based consumer path. PR:N - no prior privileges on the target host are required beyond initiating the SSH authentication exchange. UI:N - no separate user interaction is required once the target is configured this way. S:U - the effect is limited to the vulnerable SSH authentication component. C:N - no reliable confidentiality impact is established from the available evidence. I:N - no integrity impact is established from the available evidence. A:L - the demonstrated consequence is limited to out-of-bounds reads that may crash or abort the affected authentication path. Impact: Moderate. Red Hat classifies easily triggered remote denial of service issues as Important, but the trigger conditions here are materially narrower: the issue depends on GSSAPI support, non-default SSH configuration, Kerberos indicator issuance, and a specific authentication control flow. The demonstrated impact is limited to availability loss in privileged authentication code, so Moderate is a better fit than Important, while remaining above Low because the out-of-bounds iteration is concrete rather than merely theoretical. Embargo: no Reason: The issue is configuration-dependent, the demonstrated impact is limited to availability, and the proposed fix is small and low-risk. A normal public fix cycle appears more appropriate than an embargo. Acknowledgement: Aisle Research Vulnerability Details: In sshgssapigetindicators(), the client->indicators array is reallocated from count to count + 1 elements and the newly added slot is immediately filled with a newly allocated string: c client->indicators = xrecallocarray(client->indicators, count, count + 1, sizeof(char)); if (client->indicators == NULL) { fatal("sshgssapigetindicators failed to allocate memory"); } client->indicators[count] = xmalloc(value.length + 1); memcpy(client->indicators[count], value.value, value.length); client->indicators[count][value.length] = '\0'; count++; In this source tree, xrecallocarray() wraps recallocarray(), which zeroes only the newly added region when the allocation grows. Here the newly added region is exactly one pointer wide, and that pointer is overwritten before count is incremented. As a result, once at least one authenticated indicator is collected, there is no guaranteed trailing NULL entry after the last valid element even though later code relies on sentinel termination. Two consumers iterate until NULL: c if (gssapiclient.indicators != NULL) { for (i = 0; gssapiclient.indicators[i] != NULL; i++) free(gssapiclient.indicators[i]); free(gssapiclient.indicators); } c for (i = 0; client->indicators[i] != NULL; i++) { ret = matchpatternlist(client->indicators[i], options.gssindicators, 1); ... } These loops may read beyond the allocated pointer array while searching for a terminator. On the sshgssapiuserok() failure cleanup path, that out-of-bounds read may also cause free() to be called on a non-owned pointer if adjacent heap contents are interpreted as another indicator entry. Based on the available evidence, the established security consequence is an availability problem; reliable confidentiality or integrity impact is not demonstrated. Steps to reproduce: 1. Build openssh-10.2p1-10.1.hum1 with GSSAPI support and memory sanitizers such as ASan/UBSan. 2. Run sshd with GSSAPIAuthentication yes. 3. Authenticate with a Kerberos ticket that contains at least one authenticated auth-indicators name attribute. 4. Trigger a sentinel-based consumer by either causing sshgssapiuserok() to return false, for example through principal-to-local-user authorization failure, or by configuring GSSAPIIndicators so sshgssapicheckindicators() iterates the list. 5. Observe a sanitizer-reported read past the end of the indicators pointer array; depending on heap layout, cleanup may also attempt to free a non-owned pointer. Mitigation: Disabling GSSAPIAuthentication removes the remotely reachable path. If GSSAPI authentication is required, avoiding GSSAPIIndicators removes one consumer but does not remove the cleanup path after sshgssapiuserok() failure; the safer temporary mitigation is to restrict or disable use of Kerberos tickets carrying authenticated auth-indicators values until a fix is deployed. Proposed Fix: Ensure sshgssapigetindicators() leaves a dedicated trailing NULL slot after indicator collection so all sentinel-based consumers remain within bounds. diff diff --git a/gss-serv.c b/gss-serv.c @@ done: - / slot [count] is zeroed by recallocarray, serves as NULL sentinel / + / + Ensure a trailing NULL sentinel for sentinel-based consumers. + / + if (client->indicators != NULL) + client->indicators = xrecallocarray(client->indicators, + count, count + 1, sizeof(char )); ------ This report was generated using AI technology. Always review AI-generated content prior to use

Last updated 22 September 2026

In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).

Last updated 13 July 2026

Last updated 13 July 2026

scp in OpenSSH before 10.4 may place a file in the parent directory of an intended directory when the copy occurs between two remote destinations.

In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in sshconfig.