7-Zip has patched a heap-based buffer overflow in its XZ decompression code. A specially crafted archive could run arbitrary code the moment a victim extracted it. This 7-Zip vulnerability, tracked as CVE-2026-14266, sat unnoticed in the codebase for years before a researcher caught it this spring.
Trend Micro’s Zero Day Initiative published the advisory on July 15, as ZDI-26-444. The bug rates 7.0 on the CVSS scale, High severity. The fix landed three weeks earlier, in 7-Zip 26.02, released June 25. Anyone who updated promptly got a head start over the public writeups.
Where the 7-Zip vulnerability lives
The flaw traces to a single function: MixCoder_Code in C/XzDec.c. 7-Zip processes chunked XZ data through a filter. On every pass, the decoder was handed the full length of the output buffer, not what remained after earlier writes. Each write chunk believed it had more room than it actually had. A maliciously structured archive could push the decoder past the end of a heap-allocated buffer.
That is a classic heap overflow. Heap overflows in a widely deployed C parser are exactly the kind of bug attackers build reliable exploit chains around. ZDI’s writeup is blunt about the impact: an attacker who gets a crafted file in front of a victim can execute code with that user’s privileges.
Version 26.02 closes the gap. It tracks bytes already written and stops before the running total exceeds the buffer’s real size, a small fix for a bug that survived a long stretch of releases.
Who found it, and how long it sat there
Landon Peng of Lunbun LLC reported the issue to 7-Zip’s maintainers on June 5. ZDI’s coordinated disclosure process ran for six weeks before the advisory went public. According to ZDI’s affected-version list, the bug reaches back to 7-Zip 21.07, first released in 2021. It persists through every stable build up to 26.01.
That is a five-year window during which the code shipped with this 7-Zip vulnerability. There is no evidence anyone found and used it maliciously before Peng’s report. No public proof-of-concept exploit is circulating this week, and ZDI’s advisory flags no observed in-the-wild activity.
What triggers it
Exploitation needs a victim to act. Someone has to open or extract a crafted XZ archive, delivered by email, a compromised download link, or a fake update package. The CVSS vector marks the attack as local, with high complexity, requiring user interaction. This is not a wormable, zero-click flaw. But it is exactly the delivery mechanism attackers already favour for initial access. Archive files routinely slip past mail filters that scrutinise executables more closely.
There is a modest limit on Windows, though. Even from an admin account, 7-Zip usually runs under a filtered, standard-user token by default. An attacker still needs a separate step to gain full admin rights. That lowers the risk, but does not remove it. A user’s own files and login session need no admin rights to steal.
7-Zip’s own update model works against defenders here. The tool has no built-in auto-update feature. A patch release does nothing for the installed base until users fetch it themselves from 7-zip.org. That gap, between a patch existing and a patch being installed, is where most real-world exploitation of archive tools has historically happened.
Form matches a pattern
This is not the first time a 7-Zip bug has mattered in the real world. In February 2025, researchers caught Russian-linked crime groups exploiting CVE-2025-0411, a Mark-of-the-Web bypass in 7-Zip. The targets were Ukrainian government and business organisations. The campaign used double-archived files with homoglyph filenames, disguised as Word documents. It delivered SmokeLoader malware through phishing emails and ran for months before the bypass was patched.
The mechanism differs this time: heap corruption, not a missing security flag. But the delivery model is the same. An archive utility that most people trust implicitly sits between a phishing email and code execution on the desktop.
What to do about this 7-Zip vulnerability
Update to 7-Zip 26.02 or later now, on every machine where it is installed. Don’t wait for the next patch cycle. Because there is no auto-updater, this means pushing it through whatever software deployment tooling your organisation already uses for third-party applications. Don’t assume users will do it themselves.
Where mass patching will take time, treat unsolicited XZ, 7z and nested archive attachments with the same suspicion as executables at the mail gateway. Remind users that “just extract it to see what’s inside” is exactly the behaviour this bug depends on.
It is also worth checking whether 7-Zip is bundled inside other tools your organisation runs, rather than installed as a standalone application. Backup utilities, installers and archiving plugins sometimes embed the 7-Zip codebase directly. Those copies will not update just because the standalone application does. Each embedded instance needs its own version check before you can call the fleet clear of this 7-Zip vulnerability.
