Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
PuTTY's EdDSA signature verification (used for Ed25519 and Ed448 keys) accepts signatures whose value of s is out of range. According to RFC 8032, it should reject values of s greater than or equal to the order of the curve's base point. Instead, PuTTY reduces large values of s modulo that order.
This causes a property known as "signature malleability": given a valid signature for a message, an attacker can modify it into a different signature which is still accepted. But it doesn't allow an attacker to create a signature on any data for which it did not already have a valid signature from the same key.
RFC 8032 says that "some systems" depend on the absence of signature malleability (also known as "strong unforgeability"), and would consider it to be a security vulnerability. However, RFC 8032 is more general than just SSH, and does not say which systems do depend on strong unforgeability.
This issue was reported to us by email in February 2026, and in March 2026, was disclosed in the manner of a vulnerability, via a Github repository describing itself as a proof of concept. Since it was at least considered a potential vulnerability, it has a CVE ID, CVE-2026-4115. However, with respect to the reporter, in the context of an SSH client in particular, we don't believe this is a vulnerability.
PuTTY verifies Ed25519 signatures in two contexts:
1. Verifying the server's signature during key exchange. In the initial key exchange, the signature is sent in clear, so an attacker on the wire could modify it into an equivalent non-canonical form. However the bits of that signature are not used in any further part of the SSH protocol: in particular, they are not used as input to any hash or MAC for the following encrypted session. So modifying the network traffic in this way makes no difference to the rest of the session.
2. Verifying a CA signature on a host key certified using the OpenSSH certificate system. Again, during the initial key exchange, an on-path attacker could modify the certificate to change the CA's signature into an equivalent non-canonical form. An effect would be to change the fingerprint of the certified host key; one could imagine a nuisance-level DoS attack resulting from this, if you managed to poison someone's host key cache so that they distrusted the true key. But the entire certified host key is also fed into the key exchange hash, so another effect would be to prevent the server's signature on that hash (which would have used the true version of the certificate) from validating. And PuTTY checks that the signature is valid before checking the host key against its cache or prompting the user about it. So the user would never see the modified key fingerprint in the first place: they would get a message about signature validation failure first.
Following links from the above Github issue suggests that this report was related to a 2021 paper "The Provable Security of Ed25519: Theory and Practice". That paper seems to say on page 3 that there is a real threat to SSH from Ed25519 signature malleability (my emphasis):
In 2014, SSH was proven to be secure even when the same signing key is used across multiple ciphersuites, assuming that the underlying signature is strongly unforgeable. However, SSH implementations may use the originally-proposed version Ed25519-Original, which does not satisfy SUF-CMA. This yields a counterexample in their security model: mauling a signature in an otherwise honest session allows a session-key reveal on the peer, as the sessions no longer match. Thus, their proof does not apply as-is to SSH implementations that use Ed25519-Original.
The 2014 security proof referred to is "Multi-ciphersuite security of the Secure Shell (SSH) protocol".
That looks as if it's saying that signature malleability can cause an exposure of the session key. If that were true, then of course it would be a very serious vulnerability. But the language is very misleading! The 2014 paper is attempting to prove the security of (this particular aspect of) SSH, and therefore it must overestimate rather than underestimate the attacker's capabilities. In particular, the imaginary attacker in the security proof is provided with an extremely powerful query called Reveal, which allows it to request the session key from an arbitrary SSH session – but the rules of the proof are that it can only do this for SSH sessions that aren't the same as the one it's currently trying to break. In other words, the paper is trying to show that even if you're MITMing a lot of concurrent SSH sessions with the same server and have already broken all but one of them, the information you get from those other sessions still doesn't let you break the last one.
When the 2021 paper says that mauling a signature "allows a session-key reveal", it doesn't mean "allow" in the sense of "enable" (rendering an attacker capable of computing a thing that they previously couldn't compute). It means it in the sense of "permit": the absurdly overpowered attacker imagined by the 2014 security proof is now permitted to call its Reveal function, because of the technicality that two signatures aren't bitwise identical and so two of the objects in the proof that model SSH sessions are not precisely the same as each other.
In other words, all this is saying is that the proof is invalid (as the final sentence of that snippet also says – "does not apply as-is"). But a hole in a proof does not imply the result is untrue – often it merely implies that something remains to be proved by another method. In this case, it seems clear that that is indeed what's going on.