7-Zip Carried a Hidden Code Execution Flaw in Its XZ Files for Eight Years

You opened an archive in 7-Zip, and the code that let it take over your machine had been sitting there since 2018. It was quietly patched on June 25. You were not told what it fixed until three weeks later.

On July 15, the Zero Day Initiative laid out the details in advisory ZDI-26-444, tracked as CVE-2026-14266. It described a flaw in 7-Zip that lets a malicious archive run code the moment you open it. Before that day, the only thing 7-Zip had said about it was a June release that explained nothing.

7-Zip can open .xz files, a format many programs use to make files smaller. Some of those files are packed in more than one step. The data first runs through a chain of filters, for example a delta or BCJ filter, and then through the main LZMA2 compression on top.

To open one, 7-Zip grabs a single block of memory and unpacks the data into it. It keeps a running count of how many bytes it has put in there so far. In the code that count is called outWritten.

Each time it unpacks another piece, the code has to tell the decoder how much room is still free in that block. That should be the size of the block minus what it already filled. It got this wrong. It handed over the full size on each pass, as if the block were still empty.

You can see the bug in one line, in the file C/XzDec.c, in a function called MixCoder_Code:

1

destLen2 = destLenOrig;

destLenOrig is that full size. outWritten, the part already filled, never gets taken off it. So on a later pass, when the block is already half full, the decoder is still cleared to write a full block of data, and it lands past the end. Writing past the end of the block is the heap buffer overflow.

Version 26.02 adds the missing subtraction:

1
2
3
4
5
6
7

destLen2 = destLenOrig;
if (p->numCoders != 1)
{
  if (destLen2 < p->outWritten)
    return SZ_ERROR_FAIL;
  destLen2 -= p->outWritten;
}

Now the decoder gets the room that is left, and it stops with an error if the count has already run past the block. That safety check only kicks in when there is a filter chain. That is why a normal .xz is fine and a rigged one is not. It is the same “XZ chunked data” the advisory points to.

A rigged .xz sets this up on purpose. It uses a filter chain and piece sizes that force the decoder to write in several passes, so the last write runs off the end of the block. The code runs with the same rights as whoever opened the file. You get no warning and you click nothing extra. Opening the archive is enough to set it off.

The line was not new. It first appeared in early 2018, when 7-Zip rewrote its xz decoder to unpack with more than one thread at a time. The version before that rewrite does not have the bug. The one right after does, and it stayed there until the fix, more than eight years in the open.

That last part is why the score matters. Several sites called this bug “Critical.” The Zero Day Initiative, the group that found and rated it, scored it 7.0, which is High, not Critical. No source put a 9-point-something number on it. Two things hold it down. The attacker cannot reach you over the network, so they have to get a file onto your machine and get you to open it in a vulnerable copy of 7-Zip. And the score carries a High attack complexity, which means something outside the attacker’s control has to line up before the overflow turns into working code.

The strange part is how 7-Zip handled it. The fix went into version 26.02 on June 25. The changelog note for that release reads, in full:

1
2

26.02          2026-06-25
- Some bugs and vulnerabilities were fixed.

That line names no CVE, does not mention XZ, and gives no sign that one of those bugs let a file take over your computer. One release earlier, in 26.01, the same developer named the CVE and the component plainly, a heap overflow in the NTFS handler. This release said nothing of the kind. And 7-Zip has no auto-update, so the only people protected on June 25 were the ones who happened to reinstall.

This is not the first quiet 7-Zip fix. In late 2024, 7-Zip patched a Mark-of-the-Web bypass, CVE-2025-0411. That changelog described the behavior but never named the CVE, and attackers were already using the bug against targets in Ukraine before it went public.

The WinRAR release the same week makes it odder. Five days after the 7-Zip fix, WinRAR shipped version 7.23 on June 30. It fixed its own heap overflow, this one in the code that rebuilds RAR recovery volumes. But its changelog also carried this line:

1

7zxa.dll 7z extraction library is updated to version 26.02 to include bug and vulnerability fixes by the library developer.

WinRAR 7.23 ships the patched 7-Zip 26.02 library inside it. In the same week, two of the most-used archive tools on Windows both closed heap overflows. One of them was carrying the other’s fix along for the ride. WinRAR never named the 7-Zip CVE either. You had to line up the version numbers yourself to see it.

One thing to clear up, because the letters cause confusion. This is not the 2024 xz backdoor. That was malicious code deliberately slipped into the Linux xz-utils library to backdoor SSH servers. This is an accidental memory bug in 7-Zip’s own decompression code. Different software, different cause, different threat. They share two letters and nothing else.

Archive tools keep getting hit in the same place. 7-Zip’s NTFS handler in April. Its Mark-of-the-Web handling in 2024, exploited in the wild. WinRAR’s recovery-volume code, which took a heap overflow three years ago and another one now, the same corner of the code twice. A tool that unpacks files has to read whatever is inside them, and that is where the bugs keep turning up.

So how worried should you be? As of today there is no public proof-of-concept and no sign of exploitation in the wild. The researcher who reported it, Landon Peng of Lunbun LLC, found a 7-Zip bug before and put out a working proof-of-concept for that one, but he has not released attack code for this bug. For a home user, this is a patch-and-move-on situation. If you run it across a fleet of machines, update before a working exploit shows up. This class of bug tends to get weaponized once someone writes the first one.

What to do:

• → Open 7-Zip, click Help, then About, and check your version
• → If it is below 26.02, download the latest from 7-zip.org and install it
• → Do the same for WinRAR if you use it, version 7.23 or newer
• → Treat unexpected .xz and other archive files the way you treat any attachment

A file that runs code the moment you open it is exactly the kind of client-side attack I take apart in my ethical hacking course. You learn how attackers build a payload that fires when a file is opened, how they slip it past antivirus, and how they turn a broken proof-of-concept into a working exploit:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Zero Day Initiative ZDI-26-444 | 7-Zip source and version history | RARLAB WinRAR changelog