7-Zip LZX Heap Overflow RCE via Crafted CAB (CVE-2026-125742)

TL;DR

• A heap out-of-bounds write in 7-Zip's LZX decoder lets a crafted multi-volume CAB archive run code when the victim extracts the first volume. The LZX window can shrink between volumes while the decoder keeps a stale write offset.
• 7-Zip releases before 26.06 are affected. The flaw is in the decoder, so it affects the Windows, Linux and macOS builds that share the code.
• The CVE record rates it CVSS v4.0 8.5 High, CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, and CWE-787. No exploitation in the wild is known, and CVE-2026-125742 is not in CISA's Known Exploited Vulnerabilities catalog as of November 10, 2026.
• Update to 7-Zip 26.06, released November 6, 2026, and do not extract untrusted multi-volume CAB archives until every copy is updated. See "How do I fix it?".

Am I affected?

All of these must hold:

• You run 7-Zip earlier than 26.06. The affected range in the CVE record is every version before 26.06.
• The attacker can get you to extract a crafted multi-volume CAB archive with 7-Zip, for example by email, a file share or a download.
• The extraction uses 7-Zip's own LZX decoder, which is the default for LZX-compressed CAB folders. A different archiver may carry different code.

The CVE record gives the version range as "0" through "26.06" exclusive. The fix is in the 26.06 source and in the 26.06 release published on November 6, 2026. The flaw is in CPP/7zip/Compress/LzxDecoder.cpp, which is shared by the official builds.

Check the installed version from a shell:

7zz i | head -n 3

On Windows the console executable is 7z, so run 7z i in PowerShell or Command Prompt; the graphical application shows the version under Help, then About 7-Zip. The official Linux and macOS builds install 7zz. Chocolatey and Windows Package Manager report the installed package:

choco list 7zip
winget list 7zip.7zip

If the version line reads 26.05 or earlier, the install is affected. A 26.06 install is fixed for this CVE.

How do I fix it?

Upgrade 7-Zip to 26.06 on every machine that extracts untrusted archives.

1. On Windows, install the 26.06 build from the official download page, or use a package manager: winget upgrade 7zip.7zip choco upgrade 7zip -y
2. On Linux, use your distribution package when it ships 26.06. If it does not, install the official Linux build from 7-zip.org. Confirm the version with 7zz i.
3. On macOS, install the 26.06 macOS build from the official download page and confirm the version with 7zz i.
4. Check software that bundles its own 7-Zip copy, such as installers and archive managers. Updating the system 7-Zip does not update a bundled copy.

There is no configuration switch that disables the vulnerable LZX path while keeping CAB extraction. Until every copy is updated, treat multi-volume CAB archives as untrusted code:

1. Do not extract CAB archives that arrive by email or from an untrusted download.
2. If you must inspect one, extract it in a disposable virtual machine or container as an unprivileged user.
3. Block multi-volume CAB attachments at the mail gateway. That reduces exposure; it does not fix the decoder.

What is the root cause?

The decoder keeps a write position _pos for its LZX window, and it only resets that position at a window boundary when it continues a multi-volume archive. A later volume can ask for a smaller window, and the resize frees the old buffer without resetting _pos.

This is the vulnerable continuation logic in Code_WithExceedReadWrite() at 7-Zip 26.05:

if (!_keepHistory)
{
  _pos = 0;
  _overDict = false;
}
else if (_pos == _winSize)
{
  _pos = 0;
  _overDict = true;
}
_writePos = _pos;
_unpackedData = _win + _pos;

if (outSize > _winSize - _pos)
  return S_FALSE;

_keepHistory is true when the decoder continues in the next cabinet. _pos is the current write offset, _winSize is the current window size and _win is the window buffer. On a fresh archive _pos is zeroed. On a continuation it is zeroed only when it exactly equals _winSize.

The resize happens in Set_DictBits_and_Alloc():

const UInt32 newWinSize = (UInt32)1 << numDictBits;
if (_needAlloc)
{
  if (!_win || newWinSize != _winSize)
  {
    z7_AlignedFree(_win);
    _winSize = 0;
    const size_t alloc_size = newWinSize + k_OutBufSize_Add;
    _win = (Byte *)z7_AlignedAlloc(alloc_size);
    if (!_win)
      return E_OUTOFMEMORY;
    memset(_win, 0, alloc_size);
  }
}
_winSize = newWinSize;

The function frees the old window and allocates the smaller one, then updates _winSize. It does not touch _pos. A first volume compressed with a 2 MB window can therefore advance _pos far beyond the 32 KB window that a later volume declares. When the continuation arrives, _pos still holds the larger offset.

The bounds check is the last line of the vulnerable snippet. outSize and _winSize are unsigned, and _pos is larger than _winSize. The subtraction _winSize - _pos wraps to a huge value, so the check passes. The decoder then writes at _win + _pos, which is roughly 1.3 MB past the start of the 32 KB buffer.

How is it exploited?

A crafted pair of CAB volumes drives the decoder through a large window, shrinks the window, and then delivers a continuation block that is decoded at the stale offset.

1. The attacker sends v1.cab and v2.cab. The victim extracts v1.cab with 7-Zip.
2. v1.cab contains folders compressed with a large LZX window. One folder advances _pos to the chosen offset, and another stores a shell script on disk.
3. An empty folder declares a 32 KB window. The decoder frees the 2 MB buffer, allocates a 32 KB buffer and updates _winSize, but _pos keeps the old large value.
4. v1.cab ends with a continuation pointer to v2.cab. 7-Zip opens the second volume and passes its compressed block to the LZX decoder with _keepHistory still true.
5. The bounds check underflows, and the decoder writes at _win + _pos, past the 32 KB allocation.
6. The exploit uses heap grooming so that a COutFileStream object sits at that offset. The out-of-bounds write overwrites its vtable pointer and the FILE-like fields.
7. The next write through the corrupted stream dispatches to a shifted glibc FILE vtable. That leads to _IO_file_xsputn treating the object as a FILE *, overwriting the real standard input structure, and the House of Apple 2 technique turns that into a call to system("sh r"). The script that the first volume wrote to disk is already in place, and the attacker receives a reverse shell.

The researcher tested the chain on Arch Linux x86-64 with glibc 2.44 against 7-Zip 26.04 and 26.05. The write-up describes a complete chain.

It includes a way to assemble libc addresses from a heap arena pointer without a separate leak, and reports about 30 percent success for one variant with retries. The offsets depend on the 7-Zip version, the glibc build and the heap layout. The public demonstration is Linux; the write-up does not demonstrate a Windows chain.

No in-the-wild exploitation is known. The CVE record and the researcher's write-up are the only public reports, and neither names a victim or a campaign.

How does the attack flow?

A first CAB volume advances the LZX write position under a large window. A later volume shrinks the window without resetting that position, and the continuation decode writes past the new buffer. The exploit turns that write into code execution.

What can an attacker do?

An attacker who gets a victim to extract the crafted archive runs code as the user running 7-Zip. The write-up demonstrates a reverse shell on Linux. The impact depends on that user's privileges and on the machine.

The conditions are part of the impact:

• The victim must extract the first volume with an affected 7-Zip build. Opening the archive in the file manager and listing its contents is not the demonstrated trigger; the exploit runs during extraction.
• The attacker must deliver both volumes. The second volume is opened automatically as the continuation.
• The exploit is calibrated for a specific 7-Zip, glibc and heap layout. A different build may need new offsets, and the public demonstration covers Linux x86-64.
• The code runs as the user who started 7-Zip. A standard user gets that user's files and sessions. An administrator who extracts the archive gives the attacker administrator code execution.
• No in-the-wild exploitation is known, and no public victim report exists.

The write-up's own numbers set the reliability. It reports 5 of 5 successful runs with ASLR disabled, and 19 of 64 (about 30 percent) with ASLR enabled for one variant. A miss exits with an extraction error, so retries are free. That is a working exploit, not a guaranteed one.

Why does the fix work?

The fix resets the write position and the history flag whenever the decoder allocates a new window, and it initializes both fields in the constructor. That removes the stale offset that the bounds check failed to catch.

This is the fix from commit d3296e39e1f1f92c7b41c0c3848e65640428d42d:

 CDecoder::CDecoder() throw():
+    _pos(0),
     _win(NULL),
+    _overDict(false),
     _isUncompressedBlock(false),
@@
       z7_AlignedFree
         (_win);
       _winSize = 0;
+      _pos = 0;
+      _overDict = false;
       const size_t alloc_size = newWinSize + k_OutBufSize_Add;
       _win = (Byte *)

Set_DictBits_and_Alloc() now clears _pos and _overDict in the same block that frees the old buffer. A window shrink therefore starts the continuation at offset zero in the new buffer, and the unsigned subtraction can no longer wrap. Initializing the fields in the constructor also removes the uninitialized-value case on the first allocation.

The change closes the demonstrated path. It does not change the archive format or the decoder's output, so ordinary multi-volume CAB extraction keeps working. The 26.06 release notes say only that "some bugs and vulnerabilities were fixed"; the commit is the specific fix for this CVE.

How do I check if I was compromised?

Neither the CVE record nor the researcher has published indicators of compromise. The exploit is designed to leave a shell script and to start a network connection, so look for those effects rather than a signature.

• Look for unexpected files that appeared during a CAB extraction, especially a small shell script and large numbers of small padding files. The demonstrated chain writes a script named r and uses many filler files to groom the heap.
• Review outbound connections from the machine around the extraction time, particularly connections from 7z, 7zFM or a shell started by them.
• Look for pairs of CAB files delivered together, where the first names a continuation volume. A multi-volume CAB from an untrusted source is the delivery pattern.
• On a host that extracted an untrusted CAB, preserve the extracted directory and the process and network logs before cleaning up. Then rebuild the host if you cannot rule out execution.

A failed attempt can leave no trace beyond an extraction error. The absence of a shell or a connection does not prove that the archive was harmless.

Timeline

• 2026-11-06: 7-Zip 26.06 is released with commit d3296e39e1f1f92c7b41c0c3848e65640428d42d, which resets _pos and _overDict on window allocation.
• 2026-11-10 11:57 UTC: VulnCheck reserves CVE-2026-125742.
• 2026-11-10 12:00 UTC: VulnCheck publishes the CVE record and its advisory.
• 2026-11-10: Nguyễn Trần Thanh Lâm publishes the technical write-up and the exploitation demonstration.

FAQ

Is CVE-2026-125742 exploited in the wild?

No exploitation is known. The CVE record, the VulnCheck advisory and the researcher's write-up describe a working proof of concept, not attacks. The CVE is not in CISA's Known Exploited Vulnerabilities catalog as of November 10, 2026.

Is there a public exploit?

Yes, a public technical write-up describes the full chain and includes demonstration videos. It does not link an exploit-code repository. The CVE record tags the write-up as an exploit reference, and the write-up reports measured success rates.

Does the flaw affect 7-Zip on Windows, Linux and macOS?

The vulnerable decoder is shared source. The published demonstration runs on Linux x86-64, and the write-up says the offsets need calibration for each 7-Zip, glibc and heap layout. Windows uses a different C runtime, so the exact glibc chain does not transfer, but the out-of-bounds write in the decoder does. Update every platform.

Does opening the archive trigger it, or only extracting it?

The demonstrated trigger is extraction. The decoder processes the continuation volume while it writes the extracted files. Listing the archive is a different path and was not demonstrated as a trigger.

Is 7-Zip 26.06 safe?

Yes for this CVE. 26.06 contains the fix commit and is the version the CVE record names as fixed. Check bundled copies separately, because an application that ships its own 7-Zip code is not updated by installing 26.06.

What if I cannot update immediately?

Do not extract multi-volume CAB archives from untrusted sources, and block them at the mail gateway. If you must inspect one, use a disposable virtual machine or container as an unprivileged user. Those measures reduce exposure; they do not fix the decoder.

References

• CVE-2026-125742 record, VulnCheck as the CNA, published November 10, 2026, with the CVSS v4.0 8.5 and v3.1 7.8 vectors, CWE-787 and the affected range before 26.06: https://www.cve.org/CVERecord?id=CVE-2026-125742 (checked November 10, 2026)
• VulnCheck advisory, "7-Zip before 26.06 Heap Out-of-Bounds Write via LZX Decoder in CAB Extraction", November 10, 2026, with the credit to Nguyễn Trần Thanh Lâm of Nanyang Technological University: https://www.vulncheck.com/advisories/7-zip-before-26.06-heap-out-of-bounds-write-via-lzx-decoder-in-cab-extraction (checked November 10, 2026)
• 7-Zip commit d3296e39e1f1f92c7b41c0c3848e65640428d42d, the fix that resets _pos and _overDict in Set_DictBits_and_Alloc(): https://github.com/ip7z/7zip/commit/d3296e39e1f1f92c7b41c0c3848e65640428d42d (checked November 10, 2026)
• 7-Zip 26.06 release, listed by the vendor as 2026-11-06 (the GitHub release object was created 2026-11-07): https://github.com/ip7z/7zip/releases/tag/26.06 (checked November 10, 2026)
• The vulnerable Code_WithExceedReadWrite() and Set_DictBits_and_Alloc() in CPP/7zip/Compress/LzxDecoder.cpp at tag 26.05: https://github.com/ip7z/7zip/blob/26.05/CPP/7zip/Compress/LzxDecoder.cpp#L1444-L1513 (checked November 10, 2026)
• Nguyễn Trần Thanh Lâm, "7-Zip Cabinet Window Desync: From Heap OOB Write to Remote Code Execution", November 10, 2026, the root-cause analysis, the exploit chain and the measured success rates: https://potion-brew.pages.dev/posts/7zip-cab-lzx-window-desync-rce (checked November 10, 2026)
• Chocolatey community package page for 7zip, 35,677,761 total downloads and 6,087 downloads of version 26.6.0, checked November 10, 2026: https://community.chocolatey.org/packages/7zip (checked November 10, 2026)
• CISA Known Exploited Vulnerabilities catalog JSON feed, searched for CVE-2026-125742 with no match as of November 10, 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (checked November 10, 2026)