The best patch for 7-Zip is uninstalling it (on most of your PCs)

On 15 July, the Zero Day Initiative published the details of CVE-2026-14266: a heap overflow in 7-Zip's XZ decoder that allows code execution when someone opens a crafted archive. It affects version 21.07, from 2021, and every release up to 26.01. That week's headlines talked about millions of users at risk, and the default reaction would be to rush out and update two hundred machines. We are going to suggest something else, which sounds like a provocation and rests on a very boring reason: on a good share of those machines, the best patch is to uninstall the program.

We have spent years managing corporate endpoints, and what keeps you up at night is almost never the program in the security bulletin. It is the one that has been installed on half the workforce for years, appears on no list, and for which nobody can say who decides the version. 7-Zip is the textbook example of that category, and between April and July it had two code-execution flaws.

What the advisory says, and what it doesn't

Let us start by turning the volume down, which is the rarest move in this trade. CVE-2026-14266 scores 7.0 on CVSS and its vector is AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H. Translated: the attack is local, of high complexity, and requires a person to open the crafted archive. The code that runs does so with whatever permissions 7-Zip holds at that moment, gaining no privileges of its own. Technically it is a flaw in MixCoder_Code, inside C/XzDec.c: the function was handed the full output-buffer length on each pass, instead of the space left after earlier writes.

As of 20 July there was no public proof of concept and no credible report of exploitation in the wild. We say it plainly because it is the honest thing to say: this is not an emergency. Nobody needs to come back from holiday over a 7.0 that requires the user to open the file. Going through July's Patch Tuesday and its 622 patches we already argued that whoever patches by number ends up leaving until Friday the thing that is actually being exploited.

The cheapest patch is the one you never apply

This point almost never makes the advisories, because it sells no tooling. Since late 2023, Windows 11 natively opens .7z, .rar, .tar and .tar.gz files, among eleven formats in total, leaning on the open-source libarchive library. Microsoft announced it at its Build conference and shipped it with the KB5031455 update. For the user who right-clicks and extracts, which in any office is the vast majority, nothing needs installing at all.

The small print needs saying, because there is some. Native support does not open password-protected archives, does not create RAR, and brings neither 7-Zip's file manager options nor its command line. If your systems team uses 7z.exe in scripts, if you exchange encrypted archives with customers, or if somebody works inside that interface all day, 7-Zip stays, and then it gets managed like any other piece of software. What is hard to defend is having it installed on two hundred machines because it came in the 2018 image. Every copy you remove is a copy you no longer have to patch or inventory next year.

Two code-execution flaws in two months

July's did not arrive alone. CVE-2026-48095, a heap buffer write overflow in 7-Zip's NTFS archive handler, affected version 26.00 and was fixed in 26.01, released on 27 April; the public advisory came out on 22 May. It also carries a detail worth memorising: the parser's fallback logic can route files with a .7z, .zip or .rar extension to the NTFS handler when the other handlers fail. Put another way, a file's extension does not determine which code will process it, and any mail rule along the lines of "we block .xz and we're done" is born with a limp.

Both are memory-management bugs in format parsers, which is the nature of the product more than bad luck. An extraction tool is, by definition, code that processes files somebody outside sent you, so bugs will keep showing up there, in 7-Zip and in any alternative. We think it is an excellent tool and we use it. That is precisely why we want it on the machines that need it, with its version decided by somebody, rather than spread across the whole estate out of inertia.

7-Zip doesn't update itself

Here is the knot. 7-Zip has no automatic updater: staying current means going to the official site and running the installer by hand. On a machine somebody built, handed over and never touched again, the installed version is the one from handover day. If handover was in 2019, that is where it still is.

Pull the list before the patch

To decide what gets uninstalled and what gets updated, you first need to know where it is. You can answer that today without buying anything: on a single machine, winget list already reports what is installed and on which version; across an estate, the application inventory in your endpoint management tool, whether that is Intune's discovered apps, a script pushed over GPO or your EDR's software inventory, gives you the full list in an afternoon. You already have the tool. What is usually missing is the habit of opening it.

Then there is the ugly case, the one that escapes everybody: the portable copy. A 7z.exe in a desktop folder, on a network share or on the USB stick of someone who needed it for a specific job three years ago. It does not show up in "Installed apps", winget does not list it and nobody updates it. You only see it two ways: by searching the disk for the executable, or by looking in your EDR at which binaries actually run on your machines. That second route is half the value of having EDR/MDR, and almost nobody uses it.

When you run that inventory, moreover, 7-Zip will not be alone. The same pattern will show up again: small utilities, installed years ago by somebody who needed them, with no automatic updates and nobody answering for their version. PDF readers, text editors, SSH clients, video players, runtimes that arrived bundled with something else. This month's CVE landed on 7-Zip; next month it will land on another name from that list.

For the ones who do need it

The mechanical part is the easy one. With the Windows package manager, winget install -e --id 7zip.7zip installs the official build without anyone hunting for an installer online, and winget upgrade brings current whatever is already there. For centralised deployment there is an MSI installer, with a caveat worth knowing before you standardise on it: 7-Zip's own site recommends the .exe installer over the .msi, so if you package the MSI, run it past a pilot group first. And once the version is chosen, write it down somewhere, as we argued in "latest" is not a version when talking about servers.

The afternoon that pays off

The whole exercise fits in one afternoon and has three moves. Pull the list of which machines have 7-Zip and on which version; if the inventory cannot answer that, the finding of the day is worth considerably more than the patch. Then separate who genuinely needs it from who merely has it, uninstall for the second group, and leave the first on 26.02 with a named version owner. Finish by hunting the portable copies on disk and in the EDR, which is where the 2019 build no inventory knows about lives.

There are three shortcuts we would skip. Emailing the whole company asking people to update has a well-known success rate and leaves no record of who actually did it. Blocking the .xz extension in mail and calling the matter closed runs straight into what April's bug taught about parsers. And letting this jump ahead of what is genuinely being exploited right now, or turning it into a six-month project with a new tool attached, costs more than it solves.

Software with no owner

Every program installed in your company should have an answer to three questions: who needs it, who decides its version, and how that person finds out a new one exists. It is a three-line test, and considerably more software fails it than anyone would care to admit. When a program fails all three, its version ends up being set by the date somebody installed it, which is the worst possible update policy because nobody decided on it.

The good thing about a quiet CVE like this one, with no public exploit and nobody calling at three in the morning, is that it leaves room to do the exercise calmly. The ones that arrive with active exploitation do not. If a similar bug turns up in the same program in October, the difference between an afternoon's work and a week of scrambling will be whether you know the list by heart today.

Sources (verified): CVE-2026-14266 (CVSS 7.0, vector AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H, heap overflow in MixCoder_Code in C/XzDec.c, affects 21.07 and later, fixed in 26.02 released 25 Jun 2026, reported by Landon Peng of Lunbun LLC on 5 Jun 2026, detailed by the Zero Day Initiative on 15 Jul 2026, no public PoC and no known exploitation as of 20 Jul 2026, manual update from the official site), The Hacker News, 20 Jul 2026. CVE-2026-48095 (heap buffer write overflow in the NTFS handler, affects 26.00, fixed in 26.01 released 27 Apr 2026, public advisory 22 May 2026, .7z/.zip/.rar files routed to the NTFS parser by fallback logic): SOC Prime. Published versions, release dates and .exe / .msi installers (with the .exe recommendation): 7-zip.org. Native support for eleven archive formats in Windows 11 via libarchive, announced at Build and shipped with KB5031455, with no support for password-protected archives: BleepingComputer. Package identifier 7zip.7zip in the Windows package manager: winget.run. The inventory and prioritisation criteria are ours.