PuTTY 0.71 before 0.84 has an assertion failure in ECDSA signature verification.

PuTTY 0.77 before 0.84 uses a copy of the PuTTY icon as a trust indication for TELNET data but the trust status is not cleared between proxy authentication and the main session.

PuTTY 0.72 before 0.84 has a double free in RSA KEX.

https://lists.tartarus.org/pipermail/putty-announce/2026/000042.html announces the release of PuTTY 0.84 with 3 minor security fixes, along with other bug fixes and new features.

https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsakex-double-free.html provides the following info about the first vulnerability: summary: ECDSA signature verification can be made to fail an assertion class: vulnerability: This is a security vulnerability. present-in: 0.71 fixed-in: 65b8f37c34cd80680693e813e0081cdafaf58324 (0.84)

The elliptic curve arithmetic in PuTTY contains an assertion statement which shouldn't be there. It fails an assertion if you try to add two elliptic curve points with the same y-coordinate, which is a perfectly normal thing to do and should not be a special or error case at all. (Adding points with the same x-coordinate is a special case.)

This assertion failure can be triggered during initial key exchange, by sending a carefully chosen host key and signature. The crashing calculation does not depend on any other part of the key exchange, so the malicious key and signature can be the same every time.

Verification of the host key signature occurs in PuTTY before the host key is checked against the cache. So even if you trust the server you think you're connecting to, a MITM could substitute this bogus key and signature for the real ones, and cause PuTTY to crash with an assertion failure before you received any warning about an unknown or incorrect host key.

This just about classifies as a DoS attack, and hence a vulnerability. However, it is a very minor one, on the borderline of not even counting as a vulnerability at all, because:

- A MITM between a particular client and server can always deny service in the sense of preventing a successful SSH connection setup. Nothing can be done about that. - The only interesting thing in this attack is that the MITM can cause PuTTY to crash, rather than failing with a more sensible error message (which is what happens in the same situation once this bug is fixed). - PuTTY is always compiled with assertions turned on. So the crash is only an ugly error message, and does not lead to any worse compromise. - PuTTY runs one SSH session per process, so this crash does not terminate any other running sessions. - The only potential damage is that if you had valuable information in your terminal scrollback (e.g. because you had already run one successful SSH connection in the same window, and then used the "Restart Session" menu option), you might lose that information because PuTTY crashed.

This bug applies only to elliptic curves in Weierstrass form. In PuTTY that means the NIST curves: P256, P384 and P521. Ed25519 (and Ed448) is unaffected.

Thanks to Guido Vranken for reporting this bug, and also providing an example case in the P256 curve. https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsakex-double-free.html provides the following info about the second vulnerability: summary: Server can provoke a double free in RSA KEX code class: vulnerability: This is a security vulnerability. absent-in: 7a49ff9ac1f65944434176251b0bfea9fcc44636 present-in: 6d7a6d47e68e8368216f3ab1a0d071db32d20a11 0.72 0.73 0.74 0.75 0.76 0.77 0.78 0.79 0.80 0.81 0.82 0.83 fixed-in: ba3ed53e0bf6682f89940bc2c3e83da6b1524024 (0.84)

PuTTY's implementation of the little-used RSA kex exchange method (RFC 4432) has a double-free bug: in some situations it frees an RSA key by calling the special-purpose function sshrsakexfreekey and then also calling the normal free function on the outermost struct, which is wrong, because sshrsakexfreekey already freed the whole struct.

This bug does not happen if RSA kex completes normally. The double-free only occurs on an error handling path, triggered if the key sent by the server is unexpectedly short.

This bug allows a server to provoke the double-free on purpose, because it can present only RSA kex as an option in its KEXINIT, and then deliberately send a short key. Since it happens before host key verification, a MITM can do the same. Therefore, this bug is listed as a vulnerability, since it's a remote-triggerable crash. However, we don't know of any way in which the double-free can be exploited to achieve a controllable effect.

Thanks to Ben Smyth for the report.

Apparently this was introduced during work in 2019 to make a test SSH server out of the PuTTY code (including an option to pass in a fixed key pair for RSA kex, complicating the question of whether to free it after use). Confusion was increased by the historical oddity that PuTTY's RSA keys were originally held in a struct that was not freed along with its contents. https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/telnet-trust-sigil.html descsribes the third vulnerability thusly: summary: Telnet session data is marked with trust sigils after authenticating to a proxy class: vulnerability: This is a security vulnerability. present-in: 0.77 fixed-in: 64712be3cbc4a02bda4a92ca97e8d4f294abbe9a (0.84)

During the initial authentication phase of a network connection, PuTTY marks its own prompts with a 'trust sigil': a small copy of the PuTTY icon, to the left of the text. This distinguishes prompts that PuTTY emitted itself from identical text sent by a server.

The idea is to protect against spoofing attacks in which a server lets you log in without any password, and then pretends that it's still PuTTY itself doing initial authentication, and presents a prompt for something like your SSH private key passphrase. You might be fooled into telling the server that passphrase, which shouldn't ever leave the client machine. The trust sigil offers some protection, because the server can't make PuTTY display one of those, so it can't make its spoof password prompt look just like the real one.

In the older protocols such as Telnet and Rlogin, there is no formal authentication phase in the protocol itself: if the server presents a password prompt then it does it as part of the main session data. So trust sigils are not usually shown at all.

However, there's an exception. proxy-password-prompt introduced the ability to enter a password interactively when connecting to your server through a network proxy. So a trust sigil can be used in a Telnet session: it might appear during proxy authentication, before the Telnet session itself begins at all.

When this happened in 0.83 and before, the trust status was accidentally not cleared between proxy authentication and the main session. So the whole session would have trust sigils down the left-hand side.

I committed the fix for this in public, thinking it was just a silly bug. (When your whole Telnet session has those symbols down the side, you're surely going to realise they're a mistake, and not be fooled.) But since then, I've re-thought: it is a minor vulnerability, because what if the first thing the Telnet server (or MITM) sends is a request for your proxy password, perhaps pretending your previous entry of it was unsuccessful? That's still be a piece of information you don't want attackers knowing, and you might be fooled by the trust sigil into believing the request, before you find out that the rest of your session is all marked with that same sigil. By the time you notice that, it's too late – the damage is done.

So I'm classifying this as a vulnerability, although its impact is surely very small compared to most vulnerabilities. (Especially since it requires you to be using an old insecure login protocol like Telnet.) Additionally, VulDB has issued CVE-2026-4115 for a bug fixed in this release that the maintainer does not believe is a vulnerability, as discussed in detail on: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/eddsa-overlarge-s.html

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

A vulnerability was detected in PuTTY 0.83. Affected is the function eddsaverify of the file crypto/ecc-ssh.c of the component Ed25519 Signature Handler. The manipulation results in improper verification of cryptographic signature. The attack may be performed from remote. The attack requires a high level of complexity. The exploitability is told to be difficult. The exploit is now public and may be used. The real existence of this vulnerability is still doubted at the moment. The patch is identified as af996b5ec27ab79bae3882071b9d6acf16044549. It is advisable to implement a patch to correct this issue. The vendor was contacted early, responded in a very professional manner and quickly released a patch for the affected product. However, at the moment there is no proof that this flaw might have any real-world impact.

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

The sshagentchanneldata function in PuTTY before 0.68 allows remote attackers to have unspecified impact via a large length value in an agent protocol message and leveraging the ability to connect to the Unix-domain socket representing the forwarded agent connection, which trigger a buffer overflow.

Multiple untrusted search path vulnerabilities in Putty beta 0.67 allow local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) UxTheme.dll or (2) ntmarta.dll file in the current working directory.

PuTTY 0.59 through 0.61 does not clear sensitive process memory when managing user replies that occur during keyboard-interactive authentication, which might allow local users to read login passwords by obtaining access to the process' memory.

Multiple integer overflows in the (1) sftppktgetstring and (2) fxpreaddirrecv functions in the PSFTP and PSCP clients for PuTTY 0.56, and possibly earlier versions, allow remote malicious web sites to execute arbitrary code via SFTP responses that corrupt the heap after insufficient memory has been allocated.

Multiple heap-based buffer overflows in the modpow function in PuTTY before 0.55 allow (1) remote attackers to execute arbitrary code via an SSH2 packet with a base argument that is larger than the mod argument, which causes the modpow function to write memory before the beginning of its buffer, and (2) remote malicious servers to cause a denial of service (client crash) and possibly execute arbitrary code via a large bignum during authentication.

Integer signedness error in the ssh2rdpkt function in PuTTY before 0.56 allows remote attackers to execute arbitrary code via a SSH2MSGDEBUG packet with a modified stringlen parameter, which leads to a buffer overflow.

The PuTTY terminal emulator 0.53 allows attackers to modify the window title via a certain character escape sequence and then insert it back to the command line in the user's terminal, e.g. when the user views a file containing the malicious sequence, which could allow the attacker to execute arbitrary commands.

PuTTY 0.53b and earlier does not clear logon credentials from memory, including plaintext passwords, which could allow attackers with access to memory to steal the SSH credentials.

Multiple SSH2 servers and clients do not properly handle packets or data elements with incorrect length specifiers, which may allow remote attackers to cause a denial of service or possibly execute arbitrary code, as demonstrated by the SSHredder SSH protocol test suite.

Multiple SSH2 servers and clients do not properly handle large packets or large fields, which may allow remote attackers to cause a denial of service or possibly execute arbitrary code via buffer overflow attacks, as demonstrated by the SSHredder SSH protocol test suite.

Multiple SSH2 servers and clients do not properly handle strings with null characters in them when the string length is specified by a length field, which could allow remote attackers to cause a denial of service or possibly execute arbitrary code due to interactions with the use of null-terminated strings as implemented using languages such as C, as demonstrated by the SSHredder SSH protocol test suite.

Multiple SSH2 servers and clients do not properly handle lists with empty elements or strings, which may allow remote attackers to cause a denial of service or possibly execute arbitrary code, as demonstrated by the SSHredder SSH protocol test suite.

xterm, Eterm, and rxvt allow an attacker to cause a denial of service by embedding certain escape characters which force the window to be resized.