CORE SDI SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow.
Format string vulnerabilities in OpenBSD ssh program (and possibly other BSD-based operating systems) allow attackers to gain root privileges.
OpenSSH does not properly drop privileges when the UseLogin option is enabled, which allows local users to execute arbitrary commands by providing the command to the ssh daemon.
A "buffer management error" in bufferappendspace of buffer.c for OpenSSH before 3.7 may allow remote attackers to execute arbitrary code by causing an incorrect amount of memory to be freed and corrupting the heap, a different vulnerability than CVE-2003-0695.
The SSH1 PAM challenge response authentication in OpenSSH 3.7.1 and 3.7.1p1, when Privilege Separation is disabled, does not check the result of the authentication attempt, which can allow remote attackers to gain privileges.
Integer overflow in sshd in OpenSSH 2.9.9 through 3.3 allows remote attackers to execute arbitrary code during challenge response authentication (ChallengeResponseAuthentication) when OpenSSH is using SKEY or BSDAUTH authentication.
Buffer overflow in sshd in OpenSSH 2.3.1 through 3.3 may allow remote attackers to execute arbitrary code via a large number of responses during challenge response authentication when OpenBSD is using PAM modules with interactive keyboard authentication (PAMAuthenticationViaKbdInt).
Off-by-one error in the channel code of OpenSSH 2.0 through 3.0.2 allows local users or remote malicious servers to gain privileges.
OpenSSH 5.6 and earlier, when J-PAKE is enabled, does not properly validate the public parameters in the J-PAKE protocol, which allows remote attackers to bypass the need for knowledge of the shared secret, and successfully authenticate, by sending crafted values in each round of the protocol, a related issue to CVE-2010-4252.
It was discovered that OpenSSH client did not correctly handle situations when untrusted X11 forwarding was requested and generation of the untrusted authentication cookie failed. The ssh client continued by generating fake authentication cookie and allowed remote X clients to connect the local X server. The decision if client connection was accepted was delegated to the X server which, depending on its configuration, could allow clients to open trusted X connection. This would lead to remote X clients having more privileged access to the local X server than intended.
This problem can occur when X server does not include or enable X Security extension (for X.org X server, this extension is not compiled in by default since 2007) and when it has authentication methods besides MIT cookies enabled (e.g. localuser authentication allowing all X connections from a local user who owns the X session).
Both of these conditions are satisfied on Red Hat Enterprise Linux 7 and current Fedora versions. The X server does not have X Security extension compiled in and 'xhost +si:localuser:id -un' is run from the xinit scripts. Therefore remote X clients are granted trusted access to the local X server when 'ssh -X' is used, as if 'ssh -Y' was actually used.
The X server on Red Hat Enterprise Linux 6 includes X Security extension (as of RHSA-2013:1620 - http://rhn.redhat.com/errata/RHSA-2013-1620.html - which was released as part of Red Hat Enterprise Linux 6.5) and hence does not fall back to the use of fake authentication cookie.
This issue was corrected upstream in version 7.1p2:
http://www.openssh.com/txt/release-7.1p2
Upstream commit:
https://anongit.mindrot.org/openssh.git/commit/?id=ed4ce82dbfa8a3a3c8ea6fa0db113c71e234416c
which needs to be applied after:
https://anongit.mindrot.org/openssh.git/commit/?id=f98a09cacff7baad8748c9aa217afd155a4d493f
Airport. A permissions issue was addressed with improved redaction of sensitive information.
Last updated 24 July 2024
Last updated 13 July 2026
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
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).
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.
Last updated 10 July 2026
OpenSSH 4.4 was released and mentions:
Fix an unsafe signal hander reported by Mark Dowd. The signal handler was vulnerable to a race condition that could be exploited to perform a pre-authentication denial of service. On portable OpenSSH, this vulnerability could theoretically lead to pre-authentication remote code execution if GSSAPI authentication is enabled, but the likelihood of successful exploitation appears remote.
This could only affect RHEL4 as previous RHEL did not support GSSAPI
The kbdintnextdevice function in auth2-chall.c in sshd in OpenSSH through 6.9 does not properly restrict the processing of keyboard-interactive devices within a single connection, which makes it easier for remote attackers to conduct brute-force attacks or cause a denial of service (CPU consumption) via a long and duplicative list in the ssh -oKbdInteractiveDevices option, as demonstrated by a modified client that provides a different password for each pam element on this list.
The (1) roamingread and (2) roamingwrite functions in roamingcommon.c in the client in OpenSSH 5.x, 6.x, and 7.x before 7.1p2, when certain proxy and forward options are enabled, do not properly maintain connection file descriptors, which allows remote servers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact by requesting many forwardings.
sshd in OpenSSH before 4.4, when using the version 1 SSH protocol, allows remote attackers to cause a denial of service (CPU consumption) via an SSH packet that contains duplicate blocks, which is not properly handled by the CRC compensation attack detector.
If PAM is configured to read user-specified environment variables and UseLogin=yes in sshdconfig, then a hostile local user may attack /bin/login via LDPRELOAD or similar environment variables set via PAM.
Upstream fix:
https://anongit.mindrot.org/openssh.git/commit/?id=85bdcd7c92fe7ff133bbc4e10a65c91810f88755
Debian advisory:
https://www.debian.org/security/2016/dsa-3550
It was found that the shared memory manager used by pre-authentication compression support had a bounds checks that could be elided by some optimising compilers. Additionally, this memory manager was incorrectly accessible when pre-authentication compression was disabled. This could potentially allow attacks against the privileged monitor process from the sandboxed privilege-separation process (a compromise of the latter would be required first).
CVE assignment:
http://seclists.org/oss-sec/2016/q4/708
External References:
https://www.openssh.com/txt/release-7.4
sshd in OpenSSH 3.6.1p2 and earlier, when PermitRootLogin is disabled and using PAM keyboard-interactive authentication, does not insert a delay after a root login attempt with the correct password, which makes it easier for remote attackers to use timing differences to determine if the password step of a multi-step authentication is successful, a different vulnerability than CVE-2003-0190.
A flaw was found in the OpenSSH package. For each ping packet the SSH server receives, a pong packet is allocated in a memory buffer and stored in a queue of packages. It is only freed when the server/client key exchange has finished. A malicious client may keep sending such packages, leading to an uncontrolled increase in memory consumption on the server side. Consequently, the server may become unavailable, resulting in a denial of service attack.
Last updated 13 July 2026
In sshd in OpenSSH before 10.4, DisableForwarding=yes was supposed to take precedence over PermitTunnel=yes, but did not.
OpenSSH before 3.0.1 with Kerberos V enabled does not properly authenticate users, which could allow remote attackers to login unchallenged.
OpenSSH 2.9 and earlier does not initiate a Pluggable Authentication Module (PAM) session if commands are executed with no pty, which allows local users to bypass resource limits (rlimits) set in pam.d.
OpenSSH before 2.9.9, while using keypairs and multiple keys of different types in the ~/.ssh/authorizedkeys2 file, may not properly handle the "from" option associated with a key, which could allow remote attackers to login from unauthorized IP addresses.