PuTTY vulnerability argon2-parameter-checks

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Argon2 parameters not checked when read from a PPK file
class: vulnerability: This is a security vulnerability.
absent-in: 0.74
present-in: 08d17140a00481603f9692cc2989dba2d103a1ad
fixed-in: e489ded409f55391594af63038c73f4612c91f86 (0.85)

Version 3 of the PPK file format for SSH-2 private keys, introduced in PuTTY 0.75 in 2015, uses the Argon2 password hashing algorithm to process the user's passphrase into a key for encrypting the file. Argon2 has various parameters controlling how much memory and time must be spent on hashing the password, to make brute-force attack impractical. The PuTTY tools did not check those parameters for validity when reading them back from a saved key file, which allowed a malicious key file to overflow a buffer in the password hashing code, and cause (at least) a crash.

This was reported to us as a vulnerability. It's very borderline, but it is a vulnerability, just about. But exploiting it requires both an unusual use case and luck:

The attack comes from a malicious private key file. So if you always generate your own keys, you're safe. You can only be attacked if someone else provides you with a PPK file.

The attack writes randomised data outside the buffer. The overflow happens in the Argon2 code, which generates pseudo-random data in large volume by hashing the passphrase repeatedly. We have no reason to think that this buffer overflow can be exploited in a controlled way, to influence PuTTY's behaviour in a specific way.

So normally this would just be a denial of service: the PuTTY tool that loads the malicious key simply crashes, and terminates. Moreover, it's the uninteresting kind of denial of service: any PPK file of this kind is invalid, so even if PuTTY didn't crash, you still wouldn't make any successful SSH connections. Someone providing you with a nonsense private key can always "deny server" in that sense.

However, if the tool loading the malicious key is not PuTTY itself but Pageant, and if Pageant is also storing any other private key(s) at the moment that it is attacked, then there's an outside chance – in the sense that we can't prove it's impossible – that the crash might confuse Pageant into somehow leaking details of its other keys. Even so, leaking them over the network is exceptionally unlikely, since Pageant doesn't contain code to make network connections!

So, if you're using Pageant, and let someone else give you a PPK file, and it's not the only private key you store in Pageant at a time, then it's just possible you could be vulnerable.

Thanks to Christian Terörde for discovering this bug.


If you want to comment on this web site, see the Feedback page.
Audit trail for this vulnerability.
(last revision of this bug record was at 2026-08-16 13:39:29 +0100)