Activity Feed

Update: Nov 27, 2024 – Added an example of how to generate and reach the suspicious code path that was patched.

Ratings

This vulnerability was introduced into 7zip in version 24.05 (released circa May 15, 2024), and then fixed in version 24.07 (released circa June 19, 2024), so therefore the vulnerability was only present in two releases over a 1 month period. This should greatly limit the impact of the vulnerability, and I have rated the attacker value as Very Low because of this. I have tagged this vulnerability Vulnerable in default configuration, as no additional configuration is required if running a vulnerable version 24.05 or 24.06.

I have tagged this vulnerability as Requires user interaction, as when using the UI, a user must extract a file from a malicious ZSTD archive, rather than just view or open the file. We should note however that 7zip may be used as either a library or console application in a pipeline on some Linux-like systems, and in that context, may extract files automatically (e.g. if inspecting the contents of compressed archives as part of the pipeline).

This vulnerability appears to lead to heap based memory corruption, which is difficult to exploit in many scenarios, especially in a client-side file-format scenario. On Windows, while 7zip does enable the ASLR and DEP mitigations, newer mitigation such as CFG and CET are not enabled. While exploitation of this vulnerability may be non-trivial, it cannot be ruled out. There is no known exploit code currently available. Therefore I have rated the exploitability as Very Low and tagged it as Difficult to weaponize.

The Patch

We know the vulnerability affects the 7zip implementation of Zstandard decompression (see RFC 8878), and the advisory states that version 24.07 patches the vulnerability. If we inspect the code changes between version 24.06 and 24.07, the below change to the file C/ZstdDec.c stands out.

C:\Users\sfewer\Desktop\7zipOverflow\7zip>git diff 24.06..24.07 C\ZstdDec.c
diff --git a/C/ZstdDec.c b/C/ZstdDec.c
index ac159d6..6ad47eb 100644
--- a/C/ZstdDec.c
+++ b/C/ZstdDec.c
@@ -1,5 +1,5 @@
 /* ZstdDec.c -- Zstd Decoder
-2024-05-26 : the code was developed by Igor Pavlov, using Zstandard format
+2024-06-18 : the code was developed by Igor Pavlov, using Zstandard format
              specification and original zstd decoder code as reference code.
 original zstd decoder code: Copyright (c) Facebook, Inc. All rights reserved.
 This source code is licensed under BSD 3-Clause License.
@@ -1308,8 +1308,10 @@ FSE_Decode_SeqTable(CFseRecord * const table,
   in->len--;
   {
     const Byte *ptr = in->ptr;
-    const Byte sym = ptr[0];
+    const unsigned sym = ptr[0];
     in->ptr = ptr + 1;
+    if (sym >= numSymbolsMax)
+      return SZ_ERROR_DATA;
     table[0] = (FastInt32)sym
       #if defined(Z7_ZSTD_DEC_USE_ML_PLUS3)
         + (numSymbolsMax == NUM_ML_SYMBOLS ? MATCH_LEN_MIN : 0)

The function FSE_Decode_SeqTable has been patched to ensure a value sym, which is read from some input, is not greater or equal to a maximum value called numSymbolsMax. Additionally, the data type of sym has been changed from Byte to unsigned.

The addition of a check against a max value is suspicious, as is the change in data type when we see that sym is later cast to a type FastInt32. Although upon inspection, both Byte and FastInt32 appear to be unsigned data types, so I would not expect sign extension to occur here when casting.

To explore the patch further, we will build a test cast to reach this code path.

Building 7zip

We will create a Debug build of the 7zip File Manager UI application on Windows. This will allow us to do source level debugging in WinDbg later on.

First we checkout the 7zip source code and switch to a vulnerable branch for version 24.06.

C:\Users\sfewer\Desktop\7zipOverflow>git clone https://github.com/ip7z/7zip

C:\Users\sfewer\Desktop\7zipOverflow>cd 7zip

C:\Users\sfewer\Desktop\7zipOverflow\7zip>git checkout 24.06

C:\Users\sfewer\Desktop\7zipOverflow\7zip>git status
HEAD detached at 24.06

To create debug build, we need to modify a single make file (thanks to this StackOverflow question).

diff --git a/CPP/Build.mak b/CPP/Build.mak
index afb7ae8..93a383d 100644
--- a/CPP/Build.mak
+++ b/CPP/Build.mak
@@ -69,7 +69,7 @@ CFLAGS_WARN_LEVEL = -W4
 CFLAGS_WARN_LEVEL = -Wall
 !ENDIF

-CFLAGS = $(CFLAGS) -nologo -c -Fo$O/ $(CFLAGS_WARN_LEVEL) -WX -EHsc -Gy -GR- -GF
+CFLAGS = $(CFLAGS) -nologo -c -Fo$O/ $(CFLAGS_WARN_LEVEL) -WX -EHsc -Gy -GR- -GF /Zi

 !IF "$(CC)" == "clang-cl"

@@ -132,13 +132,13 @@ CFLAGS = $(CFLAGS) -D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE
 !ENDIF

 !IF "$(PLATFORM)" == "x64"
-CFLAGS_O1 = $(CFLAGS) -O1
+CFLAGS_O1 = $(CFLAGS) -Od
 !ELSE
-CFLAGS_O1 = $(CFLAGS) -O1
+CFLAGS_O1 = $(CFLAGS) -Od
 !ENDIF
-CFLAGS_O2 = $(CFLAGS) -O2
+CFLAGS_O2 = $(CFLAGS) -Od

-LFLAGS = $(LFLAGS) -nologo -OPT:REF -OPT:ICF -INCREMENTAL:NO
+LFLAGS = $(LFLAGS) -nologo -OPT:REF -OPT:ICF -INCREMENTAL:NO /DEBUG

 !IFNDEF UNDER_CE
 LFLAGS = $(LFLAGS) /LARGEADDRESSAWARE

With the make file modified to generate a debug build, we open up an x64 Native Tools Command Prompt for Visual Studio and issue an nmake command.

C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip>nmake

The vulnerable decompression code is located in the 7z.dll binary. We copy the build artifacts 7z.dll, 7z.pdb, 7zFM.exe, 7zFM.pdb to a separate folder to ensure they load (we also had 7zip installed locally via an MSI installer). We can then launch the UI via the 7zFM.exe executable.

Generating a ZSTD file

As the Zstandard algorithm was originally developed by Meta, we can generate a valid ZSTD compressed file using the reference implementation.

We clone and build the reference implementation, and then use the zstd tool to compress a file that contains 1024 letter A characters.

sfewer@sfewer-ubuntu-vm:~/Desktop$ git clone https://github.com/facebook/zstd
Cloning into 'zstd'...
remote: Enumerating objects: 61600, done.
remote: Counting objects: 100% (49/49), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 61600 (delta 16), reused 41 (delta 12), pack-reused 61551 (from 1)
Receiving objects: 100% (61600/61600), 38.02 MiB | 31.86 MiB/s, done.
Resolving deltas: 100% (46033/46033), done.
sfewer@sfewer-ubuntu-vm:~/Desktop$ cd zstd/
sfewer@sfewer-ubuntu-vm:~/Desktop/zstd[dev]$ make
make[1]: Entering directory '/home/sfewer/Desktop/zstd/lib'
CC obj/conf_6dfaa674569dd42c9d9861c915b0e7c2/static/debug.o
CC obj/conf_6dfaa674569dd42c9d9861c915b0e7c2/static/entropy_common.o
CC obj/conf_6dfaa674569dd42c9d9861c915b0e7c2/static/error_private.o
CC obj/conf_6dfaa674569dd42c9d9861c915b0e7c2/static/fse_decompress.o
CC obj/conf_6dfaa674569dd42c9d9861c915b0e7c2/static/pool.o

...snip...

CC obj/conf_20daa47e8058f816896e54abab38685b/zstdcli.o
CC obj/conf_20daa47e8058f816896e54abab38685b/zstdcli_trace.o
==> building with threading support
==> building zstd with .gz compression support
==> building zstd with .xz/.lzma compression support
==> no liblz4, building zstd without .lz4 support
LINK obj/conf_20daa47e8058f816896e54abab38685b/zstd
zstd build completed
make[1]: Leaving directory '/home/sfewer/Desktop/zstd/programs'
sfewer@sfewer-ubuntu-vm:~/Desktop/zstd[dev]$ ./zstd --version
*** Zstandard CLI (64-bit) v1.5.7, by Yann Collet ***
sfewer@sfewer-ubuntu-vm:~/Desktop/zstd[dev]$ ./zstd ~/Desktop/A.txt 
/home/sfewer/Desktop/A.txt :  2.34%   ( 1.000 KiB =>     24 B, /home/sfewer/Desktop/A.txt.zst)

We can examine what a valid ZSTD file looks like:

sfewer@sfewer-ubuntu-vm:~/Desktop/zstd[dev]$ xxd ~/Desktop/A.txt.zst 
00000000: 28b5 2ffd 6400 0355 0000 1841 410a 0100  (./.d..U...AA...
00000010: fa2b 8005 33ac 8ae1                      .+..3...
sfewer@sfewer-ubuntu-vm:~/Desktop/zstd[dev]$

Reaching the vulnerable code path

By setting a breakpoint in WinDbg, we can observe that some data from our test file is processed by 7z!FSE_Decode_SeqTable.

0:007> bp 7z!FSE_Decode_SeqTable
*** WARNING: Unable to verify checksum for C:\Users\sfewer\Desktop\7zipOverflow\debug\7z.dll
0:007> g
Breakpoint 0 hit
7z!FSE_Decode_SeqTable:
00007ff9`c1e1ffd0 4c894c2420      mov     qword ptr [rsp+20h],r9 ss:000000ba`080ff3e8=0000000000020110
0:007> t
7z!FSE_Decode_SeqTable+0x18:
00007ff9`c1e1ffe8 83bc249000000002 cmp     dword ptr [rsp+90h],2 ss:000000ba`080ff400=00000000
0:007> k
 # Child-SP          RetAddr               Call Site
00 000000ba`080ff370 00007ff9`c1e2229b     7z!FSE_Decode_SeqTable+0x18 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 1284] 
01 000000ba`080ff3d0 00007ff9`c1e23819     7z!ZstdDec1_DecodeBlock+0x81b [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 2531] 
02 000000ba`080ff4d0 00007ff9`c1e22b41     7z!ZstdDec_DecodeBlock+0x709 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 3442] 
03 000000ba`080ff5e0 00007ff9`c1dd6569     7z!ZstdDec_Decode+0x2c1 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 3737] 
04 000000ba`080ff6c0 00007ff9`c1cec350     7z!NCompress::NZstd::CDecoder::Code+0x159 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\Compress\ZstdDecoder.cpp @ 164] 
*** WARNING: Unable to verify checksum for C:\Users\sfewer\Desktop\7zipOverflow\debug\7zFM.exe
05 000000ba`080ff750 00007ff6`0acb66e0     7z!NArchive::NZstd::CHandler::Extract+0x440 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\Archive\ZstdHandler.cpp @ 821] 
06 000000ba`080ff910 00007ff6`0acc3343     7zFM!CAgentFolder::Extract+0x630 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\Agent\Agent.cpp @ 1555] 
07 000000ba`080ffad0 00007ff6`0acf4da6     7zFM!CAgentFolder::CopyTo+0x193 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\Agent\ArchiveFolder.cpp @ 46] 
08 000000ba`080ffb80 00007ff6`0ad21de0     7zFM!CPanelCopyThread::ProcessVirt+0x536 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\FileManager\PanelCopy.cpp @ 112] 
09 000000ba`080ffcb0 00007ff6`0ad2093d     7zFM!CProgressThreadVirt::Process+0x40 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\FileManager\ProgressDialog2.cpp @ 1425] 
0a 000000ba`080ffd80 00007ff6`0ad370fe     7zFM!MyThreadFunction+0x1d [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\FileManager\ProgressDialog2.cpp @ 1393] 
0b 000000ba`080ffdc0 00007ff9`f0cd259d     7zFM!thread_start<unsigned int (__cdecl*)(void *),1>+0x5a [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 97] 
0c 000000ba`080ffdf0 00007ff9`f1c6af38     KERNEL32!BaseThreadInitThunk+0x1d
0d 000000ba`080ffe20 00000000`00000000     ntdll!RtlUserThreadStart+0x28

Inspecting the contents on the in structure, we see several bytes that correspond to bytes from the test case file (at offset 16).

0:007> dt in
Local var @ 0xba080ff3d8 Type CInBufPair*
0x000000ba`080ff430 
   +0x000 ptr              : 0x00000248`50970010  "???"
   +0x008 len              : 4
0:007> db 0x00000248`50970010 L8
00000248`50970010  fa 2b 80 05 33 ac 8a e1                          .+..3...

The caller to 7z!FSE_Decode_SeqTable is 7z!ZstdDec1_DecodeBlock. We can inspect the call site and see the seqMode variable originated 1 byte before the remaining data in the in structure. In our test case this byte was 0x00.

    mode = *in.ptr++;
    if (mode & 3) // Reserved bits
      return SZ_ERROR_DATA;
    
    seqMode = (mode >> 6);
    if (seqMode == k_SeqMode_Repeat)
      { if (!IS_SEQ_TABLES_WERE_SET(p)) return SZ_ERROR_DATA; }
    else RINOK(FSE_Decode_SeqTable(
        p->fse.ll,
        &in,
        6, // predefAccuracy
        &p->ll_accuracy,
        NUM_LL_SYMBOLS,
        k_PredefRecords_LL,
        seqMode))

Upon inspecting RFC8878, we learn that this seqMode variable represents Symbol_Compression_Modes, and to reach the vulnerable code path, we must set this mode to be RLE_Mode. As there are 3 different tables that are processed, the mode can be set 3 times, left shifted by 2 bits for each mode, and with the low 2 bits cleared. Therefore we patch our test case to have a Symbol_Compression_Modes value of 0x54 which is 01010100 in binary. The will give us a Literal_Lengths_Mode (LL) of RLE_Mode, a Offsets_Mode (OM) of RLE_Mode, and a Match_Lengths_Mode (ML) of RLE_Mode. So when 7z!ZstdDec1_DecodeBlock processes the current block, it will call 7z!FSE_Decode_SeqTable once for each table (LL, OM, and ML), and reach the code that was patched. If the mode is not set to RLE_Mode, the patched code path is not reached. As we know the patched function will read a single byte, and write that value to the corresponding table, we patch our testcase to have 3 consecutive 0xFF bytes.

The resulting test case looks like this.

sfewer@sfewer-ubuntu-vm:~/Desktop/zstd[dev]$ xxd ~/Desktop/A.txt.zst 
00000000: 28b5 2ffd 6400 0355 0000 1841 410a 0154  (./.d..U...AA..T
00000010: ffff ff05 33ac 8ae1                      ....3...

The result of decompressing this file in 7zipFM.exe, is the following read access violation

(24fc.2420): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for C:\Users\sfewer\Desktop\7zipOverflow\debug\7z.dll
7z!Decompress_Sequences+0x73c:
00007ff9`c1e1f52c 488b00          mov     rax,qword ptr [rax] ds:000001da`28faffec=????????????????
0:007> k
 # Child-SP          RetAddr               Call Site
00 00000072`0baff320 00007ff9`c1e22438     7z!Decompress_Sequences+0x73c [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 2210] 
01 00000072`0baff4d0 00007ff9`c1e23819     7z!ZstdDec1_DecodeBlock+0x9b8 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 2617] 
02 00000072`0baff5d0 00007ff9`c1e22b41     7z!ZstdDec_DecodeBlock+0x709 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 3442] 
03 00000072`0baff6e0 00007ff9`c1dd6569     7z!ZstdDec_Decode+0x2c1 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\C\ZstdDec.c @ 3737] 
04 00000072`0baff7c0 00007ff9`c1cec350     7z!NCompress::NZstd::CDecoder::Code+0x159 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\Compress\ZstdDecoder.cpp @ 164] 
*** WARNING: Unable to verify checksum for C:\Users\sfewer\Desktop\7zipOverflow\debug\7zFM.exe
05 00000072`0baff850 00007ff6`0acb66e0     7z!NArchive::NZstd::CHandler::Extract+0x440 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\Archive\ZstdHandler.cpp @ 821] 
06 00000072`0baffa10 00007ff6`0acc3343     7zFM!CAgentFolder::Extract+0x630 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\Agent\Agent.cpp @ 1555] 
07 00000072`0baffbd0 00007ff6`0acf4da6     7zFM!CAgentFolder::CopyTo+0x193 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\Agent\ArchiveFolder.cpp @ 46] 
08 00000072`0baffc80 00007ff6`0ad21de0     7zFM!CPanelCopyThread::ProcessVirt+0x536 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\FileManager\PanelCopy.cpp @ 112] 
09 00000072`0baffdb0 00007ff6`0ad2093d     7zFM!CProgressThreadVirt::Process+0x40 [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\FileManager\ProgressDialog2.cpp @ 1425] 
0a 00000072`0baffe80 00007ff6`0ad370fe     7zFM!MyThreadFunction+0x1d [C:\Users\sfewer\Desktop\7zipOverflow\7zip\CPP\7zip\UI\FileManager\ProgressDialog2.cpp @ 1393] 
0b 00000072`0baffec0 00007ff9`f0cd259d     7zFM!thread_start<unsigned int (__cdecl*)(void *),1>+0x5a [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 97] 
0c 00000072`0baffef0 00007ff9`f1c6af38     KERNEL32!BaseThreadInitThunk+0x1d
0d 00000072`0bafff20 00000000`00000000     ntdll!RtlUserThreadStart+0x28

Further manipulation of the test case file, showed that 7z!Decompress_Sequences may crash in several different locations, however I could not make a test case file that caused a write access violation.

On Aug 9, 2024, SolarWinds published an advisory for CVE-2024-28986, with a CVSS score of 9.8 (Critical), affecting the Web Help Desk product.

Described as an unauthenticated deserialization vulnerability that allows for RCE, in the vendor description, SolarWinds were unable to replicate the unauthenticated portion of the vulnerability. Instead SolarWinds were only able to replicate the vulnerability with authentication (i.e. valid credentials were required to trigger the vulnerability). This is a discrepancy given the CVSS rating specifies Privileges Required of None. It is unclear how this vulnerability was reported to SolarWinds, as no credit is given in the advisory. So we do not have another source of information to help clarify this discrepancy. On August 15, 2024, this vulnerability was added to the CISA KEV list, for known exploitation in the wild.

Therefore, we know that at least one exploit exists, due to the confirmed exploitation in the wild, however, to the best of my knowledge, there is no known public exploit code available.

I have rated the attacker value as High, as deserialization vulnerabilities are a reliable method to achieve RCE against a target. However the internet exposure of Web Help Desk is relatively small, with Shadowserver reporting around 800 instances of Web Help Desk on the public internet (as of Aug 18, 2024).

Due to the lack of any public exploit code I have not rated the exploitability, as we cannot know this without the availability of a suitable technical analysis or exploit code.

Critical unauthenticated remote code execution vulnerability in Veeam Backup & Replication, a perennially popular target for abuse (including by ransomware groups). Rapid7 has a blog here on this vulnerability, as well as other Veeam vulns patched over the summer of 2024.

CVE-2024-40711 is being exploited by multiple ransomware crews, including Akira, Fog, and a new group called Frag, per Sophos X-Ops. Sophos’s blog on exploitation notes they began seeing MDR cases in October 2024. The CVE was added to CISA KEV on October 17, roughly 7 weeks after it was disclosed. Cybersecurity Dive has some solid additional context here.

Veeam Backup & Replication generally shouldn’t be exposed to the internet, but several technical reports have noted that this bug is still a great target for attackers who purchase initial access to corporate networks from access brokers. Public proof-of-concept code is available. Patch this one on an emergency basis if you haven’t already.

SolarWinds Web Help Desk is described as an “Affordable Help Desk Ticketing and Asset Management Software”. On Aug 21, 2024, CVE-2024-28987 was published, disclosing a hardcoded credential vulnerability, with a CVSS score of 9.1 (Critical). On Sept 25, 2025, the original finders of the vulnerability, Horizion3, published a technical analysis and an accompanying PoC exploit. On Oct 15, 2025, the vulnerability was added to CISA’s KEV list as being known to be exploited in the wild.

The CVE record indicates that all versions of Web Help Desk, prior to the patch 12.8.3 Hotfix 2, are vulnerable.

The vulnerability lies in how authentication to the /OrionTickets endpoint of the Web Help Desk HTTP(S) service is handled. Authentication for this endpoint is performed via HTTP Basic authentication. The application code contains a hardcoded username of helpdeskIntegrationUser and an accompanying password of dev-C4F8025E7. A remote unauthenticated attacker can supply these credentials during requests to the /OrionTickets endpoint, and successfully authenticate to the service. In doing so, the attacker can then access the support tickets stored on the service, potentially disclosing sensitive information.

A Metasploit module is available, which allows an attacker to retrieve all support tickets from an affected system.

I have rated the attacker value for this vulnerability as Medium, as while an attacker can disclose sensitive information, this vulnerability cannot be leveraged for RCE. I have rated the exploitability of this vulnerability as Very High, as exploitation is trivial, and several exploits are available publicly.

CVE-2024-31497 is a cryptographic flaw (specifically CWE-338, or “Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)”) in PuTTY 0.68 through 0.80. The vulnerability allows attackers to recover and compromise private PuTTY keys — it was fixed in version 0.81, which was released April 15, 2024. Per Openwall (one of the many advisories on this issue):

“The PuTTY client and all related components generate heavily biased ECDSA nonces in the case of NIST P-521. To be more precise, the first 9 bits of each ECDSA nonce are zero. This allows for full secret key recovery in roughly 60 signatures by using state-of-the-art techniques. These signatures can either be harvested by a malicious server (man-in-the-middle attacks are not possible given that clients do not transmit their signature in the clear) or from any other source, e.g. signed git commits through forwarded agents.”

Rating this vuln relatively low for value and exploitability since it only affects 521-bit ECDSA keys, which are less common. Other key sizes and algorithms aren’t affected. The Openwall advisory notes that while the nonce generation for other curves is also slightly biased, that bias is not enough to perform lattice-based key recovery attacks. Reddit has a good series of comments on the issue, all of which are happily very down-to-earth :)

As of November 2024 there’s no known exploitation in the wild, which makes sense given the caveats to exploitation and narrow scope of the bug. A number of downstream advisories have been released for products that implement PuTTY, e.g., this Citrix XenCenter bulletin. Orgs that use 521-bit ECDSA keys should revoke and regenerate, and folks who use PuTTY in their own product implementations should update to the latest version.