CVE-2024-31497 PuTTY: How to Fix the P-521 Key Recovery Finding (Nessus 193433)

CVE-2024-31497 is a flaw in PuTTY and Pageant 0.68 to 0.80: biased ECDSA nonces let an attacker recover a NIST P-521 private key from roughly 60 signatures. Fix it by updating PuTTY and every tool that bundles it to 0.81 or later, then revoke and replace any P-521 key those versions ever used.

What the scanner is actually detecting

Tenable ships separate checks for PuTTY itself and for products that embed PuTTY code, so one workstation can raise several findings for the same CVE.

None of these plugins looks at your keys. They only prove that a vulnerable version is present. Whether a private key has already leaked depends on whether anyone used a P-521 key with that software, which you have to check yourself.

Real-world risk

The PuTTY advisory is precise about scope. Only NIST P-521 ECDSA keys (ecdsa-sha2-nistp521) are affected. RSA, Ed25519, and ECDSA P-256 and P-384 keys are not. The bug is in signing, not key generation: PuTTY generated the nonce k with its own deterministic method, and for P-521 the top 9 bits were always zero. About 60 signatures plus the public key are enough to compute the private key.

The advisory states that an attacker only needs to briefly compromise any server where you authenticate with the key, or briefly gain access to a Pageant instance holding it. The public disclosure on oss-security describes two practical scenarios: a rogue or compromised SSH server collecting signatures during logins, and Git commits signed through Pageant, whose signatures sit in public repositories and can be harvested offline. A stolen key then opens every other server and Git host that trusts it.

Tenable’s CVE page rates CVE-2024-31497 Medium (CVSS v3 5.9); plugin 193433 itself carries a CVSS v3 score of 8.1. If no P-521 key was ever used with the affected tools, this is a routine software update. If one was, updating does not help that key: the advisory stresses that information about existing P-521 keys has already leaked through every signature made with the old code.

How to confirm it on the host

List installed PuTTY and PuTTY-based products from the uninstall registry keys (run in PowerShell):

Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
  'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*',
  'HKCU:SoftwareMicrosoftWindowsCurrentVersionUninstall*' -ErrorAction SilentlyContinue |
  Where-Object DisplayName -match 'PuTTY|FileZilla|WinSCP|TortoiseGit|TortoiseSVN' |
  Select-Object DisplayName, DisplayVersion

Portable copies never appear there. Search the disks (and file shares you control) for the executables and read their version resources:

Get-ChildItem -Path C: -Recurse -Force -ErrorAction SilentlyContinue `
  -Include putty.exe,plink.exe,pscp.exe,psftp.exe,pageant.exe,puttygen.exe |
  Select-Object FullName, @{n='Version';e={$_.VersionInfo.ProductVersion}}

For any Plink found, plink -V prints the release number. Now look for exposed keys. Every PPK file starts with PuTTY-User-Key-File-<version>: <algorithm>, so P-521 keys are easy to find:

Get-ChildItem -Path C:Users -Filter *.ppk -Recurse -Force -ErrorAction SilentlyContinue |
  Select-String -Pattern '^PuTTY-User-Key-File-d+: ecdsa-sha2-nistp521' -List |
  Select-Object Path

In Pageant’s key list, affected keys are shown as NIST p521. In PuTTYgen, a loaded key shows ecdsa-sha2-nistp521 in the Key fingerprint box. On the server side, find where those keys are trusted:

grep -H 'ecdsa-sha2-nistp521' /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null

Adjust the paths if AuthorizedKeysFile in sshd_config points elsewhere, and check the SSH keys (authentication and signing) registered on your Git hosting accounts.

How to fix it

Update PuTTY on Windows

PuTTY 0.81 (released 15 April 2024) switched DSA and ECDSA signing to RFC 6979 nonces. Later releases fixed further security bugs, so install the current release (0.85 at the time of writing) rather than stopping at 0.81. With winget:

winget upgrade --id PuTTY.PuTTY --exact

Or push the official MSI through your software distribution tool. Verify the file against the SHA-256 checksums and GPG signatures published on the PuTTY download page first:

Get-FileHash .putty-64bit-0.85-installer.msi -Algorithm SHA256
msiexec /i putty-64bit-0.85-installer.msi /qn /norestart

Rerun the inventory command afterwards. A 32-bit PuTTY install next to a 64-bit one is a separate product, so remove any older entry that remains. Replace or delete every portable putty.exe, plink.exe and pageant.exe the file search found, including copies in script folders, jump-box desktops and shared tool directories.

Update products that bundle PuTTY code

Updating PuTTY does not fix these; each ships its own copy. Minimum fixed versions from the CVE record and the disclosure:

• FileZilla Client: 3.67.0 or later
• WinSCP: 6.3.3 or later
• TortoiseGit: 2.15.0.1 or later
• TortoiseSVN: 1.14.7 or later (its TortoisePlink was moved to PuTTY 0.81 code)

Linux hosts flagged by plugin 227649

This plugin fires when your distribution has not published a fixed package for your release (Ubuntu’s tracker, for example, still lists putty on 20.04 and 22.04 as needing evaluation). Check with dpkg -l | grep -Ei 'putty|filezilla' or rpm -qa | grep -Ei 'putty|filezilla'. If the package is not needed, remove it (sudo apt remove putty putty-tools). If it is needed, make sure nobody uses a P-521 key with it and record a risk acceptance until a vendor fix arrives.

Revoke and replace every exposed P-521 key

1. Generate a new key. In PuTTYgen, choose EdDSA with the Ed25519 (255 bits) curve, click Generate, set a passphrase and save the private key. Alternatively run ssh-keygen -t ed25519 with the Windows OpenSSH client and load the result via Conversions > Import key.
2. Copy the contents of the Public key for pasting into OpenSSH authorized_keys file box to every server and Git host that trusted the old key.
3. Test a login with the new key while an existing session stays open.
4. Remove the old ecdsa-sha2-nistp521 line from every authorized_keys file and delete the old key from Git hosting accounts, both as an authentication key and as a signing key.
5. Delete the old .ppk and remove it from Pageant and any startup shortcut that loads it.

How to verify the fix and rescan

1. Rerun the uninstall-key and file-search commands. Every PuTTY binary should report 0.81 or later, and FileZilla, WinSCP and TortoiseGit should be at or above the versions above.
2. Rerun the PPK search and the authorized_keys grep. Both should return nothing.
3. Rescan with a credentialed Windows policy or Nessus Agent, since plugin 193433 is a local check. Plugins 193433 and 206646 should clear once the versions are fixed.

What can break and how to roll back

• Saved sessions: PuTTY keeps them under HKCUSoftwareSimonTathamPuTTY. Back them up before a mass upgrade with reg export HKCUSoftwareSimonTathamPuTTY putty-backup.reg.
• Automation: scripts using plink -i, WinSCP stored sites and TortoiseGit remotes that point at the old .ppk fail once the old public key is removed. Update key paths before you revoke.
• Lockout: adding the new key before removing the old one avoids it. Keep console or out-of-band access to critical servers during the change.

Rolling back PuTTY to a version below 0.81 reintroduces the vulnerability, so fix the problem rather than downgrade. If a service breaks after key removal, the only rollback is re-adding the old public key, which means trusting a key you must assume is compromised. Treat that as a short, documented emergency measure only.

Common false positive reasons

• A second, older install: the 64-bit PuTTY was updated but a 32-bit or per-user install is still registered. This is a real finding, not a false positive.
• Different product: after updating PuTTY, plugin 206646 still fires because FileZilla carries its own PuTTY code.
• Not exploitable, but not wrong: a vulnerable PuTTY on a host where no P-521 key is ever used carries low practical risk, yet the version check is accurate. Update it anyway rather than suppressing it.
• Returning findings: portable copies restored from a share or a user’s downloads folder reappear after closure, a common driver of a high vulnerability recurrence rate.

FAQ

Does updating PuTTY make my existing P-521 key safe?

No. Signatures made with the vulnerable versions already leaked information about the key. Revoke and replace it.

Are RSA, Ed25519 or other ECDSA keys affected?

No. The PuTTY advisory limits the problem to NIST P-521. P-256, P-384, RSA and Ed25519 keys are unaffected.

My key came from ssh-keygen, not PuTTYgen. Does that matter?

No. What matters is whether the key was ever used for signing by PuTTY or Pageant 0.68 to 0.80, or by a product embedding that code.

Is this a server-side SSH vulnerability?

No. It affects client software. Servers only matter as places where signatures can be collected and where the compromised public key must be removed.

Tracking this finding across many hosts

On a large Windows fleet, the hard part is finding every copy and proving each one is gone. If you manage that at scale, SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results arrive as uploaded .nessus exports) and merges duplicates per scanner. Its AI-written, host-specific remediation scripts run through human approval gates and are deployed by SITEY agents on Windows and Linux endpoints, and Nessus findings can be retested individually to confirm closure.

Sources

• PuTTY advisory: vuln-p521-bias (CVE-2024-31497)
• Tenable: PuTTY < 0.81 Key Recovery Attack Vulnerability, plugin 193433
• Tenable: FileZilla < 3.67.0 Insecure Key Recovery Vulnerability, plugin 206646
• Tenable: CVE-2024-31497
• oss-security: CVE-2024-31497 disclosure