The Zero Day Initiative has published ZDI-26-444, detailing CVE-2026-14266, a heap-based buffer overflow in 7-Zip’s XZ decompression logic. The bug lives in MixCoder_Code() in C/XzDec.c and lets a specially crafted XZ-compressed stream write past the end of an allocated output buffer during decoding. 7-Zip shipped a silent fix in 26.02 on June 25, 2026; ZDI’s advisory landed three weeks later, on July 15, and CVE assignment followed. Researcher Landon Peng of Lunbun LLC is credited with the original report, submitted to the 7-Zip team on June 5.

Technical Details

7-Zip mishandles chunked data inside XZ streams: when decoding certain chunk-boundary configurations, the decoder writes output past the space actually reserved for the current buffer. The 26.02 patch adds explicit bounds checks so MixCoder_Code() cannot write beyond the remaining space in the output buffer.

The bug carries CVSS 3.1 7.0 (AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H) — high impact on confidentiality, integrity, and availability, but gated by high attack complexity and required user interaction. In practice, exploitation means an attacker crafts a malicious .xz file (or a .7z/.zip archive that embeds an XZ-compressed member, since 7-Zip’s format auto-detection will route XZ-compressed content through the same decoder regardless of container extension) and gets a victim to open or extract it with a vulnerable 7-Zip build. There is no authentication and no network prerequisite beyond delivering the file — email attachment, download link, artifact registry, shared drive.

Every 7-Zip release up to and including 26.01 is affected; the fix is in 26.02 and later. As of this writing there is no confirmed in-the-wild exploitation and no verified public proof-of-concept, though a PoC-generator repository referencing the CVE has already appeared on GitHub — treat any such tooling as unverified and handle with the same caution as the vulnerability itself.

Impact

7-Zip’s 7z/7zz/p7zip binaries are baked into infrastructure that rarely gets inventoried as “security-relevant software”: Windows build agents, CI runners that unpack vendor SDKs and release artifacts, malware-analysis sandboxes, forensic triage VMs, and Linux servers doing routine log rotation or archive ingestion. Because 7-Zip falls back to content-based format detection when a file’s extension doesn’t match its signature, an attacker doesn’t need the victim to knowingly open an .xz file — any archive or blob that a pipeline unpacks through 7-Zip’s auto-detected coder set is a reachable code path.

The practical severity is well below a network-exploitable, no-interaction RCE — high attack complexity and required user interaction keep this out of “drop everything” territory — but the blast radius (build agents, CI unpackers, forensic tooling) is the same class of high-value target that made the recent 7-Zip NTFS parser bug (CVE-2026-48095) worth patching immediately. Treat this the same way: it’s a memory-corruption primitive in code that regularly processes attacker-supplied input on machines that hold signing keys and deploy credentials.

Mitigation

  • Upgrade to 7-Zip 26.02 or later on every Windows workstation, Linux server, and CI/build agent running 7z, 7zz, or p7zip.
  • Check for distro lag: p7zip forks (Debian/Ubuntu packages, p7zip-zstd) have historically trailed upstream by weeks to months — verify your package manager is actually shipping the patched decoder, not just a version bump.
  • On macOS, audit keka and other tools that bundle 7-Zip’s decompression library.
  • In CI pipelines, avoid routing untrusted, attacker-influenced artifacts through 7-Zip’s auto-detecting extraction path where a narrower tool (unxz, tar, bsdtar/libarchive with format pinned) would do.
  • Sandbox archive-extraction steps on build agents — no host mounts, no network egress, minimum-privilege service account — since any decoder bug in this class can eventually be chained into code execution.

Advisory: ZDI-26-444. Coverage: The Hacker News.