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 ssh_rsakex_freekey and then also calling the normal
free function on the outermost struct, which is wrong, because
ssh_rsakex_freekey 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- [email protected]
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
