7-Zip CVE-2026-14266: Heap Out-of-Bounds Write in the XZ Decoder (MixCoder_Code) – Versions 21.07 through 26.01 Affected

TL;DR — 90 Seconds

Affected?

7-Zip 21.07 through 26.01 (official Windows builds from 7-zip.org) as well as all Linux packages (p7zip, distro-specific 7zip packages) that are internally based on one of these versions. Concretely, any process that extracts an XZ, .7z, or .tar.xz archive with a vulnerable 7-Zip version is affected – including automated build and CI jobs.

Risk?

Heap out-of-bounds write in the XZ decoder (MixCoder_Code, C/XzDec.c), triggerable by a crafted archive. CVSS 3.0 7.0 (AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H) per secondary assessment (Rescana) – local attack vector, user interaction required, no elevated privileges needed. The NVD entry is still RESERVED as of this writing, so no officially confirmed CVSS vector exists yet.

Immediate action?

Not a fire drill: no public exploit, no known active exploitation. But: build and CI pipelines that use 7-Zip/p7zip to auto-extract third-party archives should check and update to 26.02 or newer soon.

Recommendation?

Act this cycle if CI/build systems auto-extract untrusted archives. Verifying only is sufficient if you're already on 26.02+ or don't use 7-Zip for untrusted input.

Criticality?

medium — local vector, user interaction required, no PoC, no exploitation in the wild, but a wide version range (nearly 5 years) and relevant attack surface in automated build pipelines, where the automated extraction step itself can constitute the “user interaction” in the CVSS sense.

What Is the Problem?

7-Zip uses a dedicated decoder in C/XzDec.c for the XZ format (and containers built on it, such as .7z with LZMA2 streams, or .tar.xz). The core piece is the function MixCoder_Code, which drives the actual decompression loop over multiple passes and writes data into an output buffer provided by the caller.

The bug: on every single decompression pass, the code passed the decoder the full length of the output buffer – not the capacity actually still remaining after the bytes already written in previous passes. With a regular, well-formed archive this goes unnoticed, because input and output amounts line up. But if the data stream is deliberately crafted so that several passes in a row each “see” the full buffer size again, the decoder writes past the end of the space actually still free on every further pass – a classic heap out-of-bounds write. Depending on heap layout, allocator, and adjacent structures, this can range from a crash to controlled code execution.

The disclosure timeline is notable: 7-Zip maintainer Igor Pavlov apparently fixed the bug silently already in version 26.02 on June 25, 2026 – the changelog entry merely states, generically, “Some bugs and vulnerabilities were fixed,” with no CVE reference or security advisory. Only about three to four weeks later, on July 15 and 20, 2026 respectively, was the flaw publicly linked to CVE-2026-14266 and documented, via a ZDI advisory and subsequent secondary reporting. This pattern – a silent fix in a point release, followed by retroactive CVE assignment weeks later – is not a one-off for 7-Zip: Pavlov routinely fixes security issues without an accompanying advisory, which means that simply “reading the release notes” is not a reliable security process. Anyone relying exclusively on CVE feeds instead of version diffs may well be weeks behind reality.

Who Is Affected?

The vulnerable code path lives in 7-Zip's shared C source and therefore plays out differently across distribution channels:

Important transparency note: for other distributions (e.g. openSUSE, Alpine, and commercial Linux derivatives) no reliable, current package version could be verified as part of this research. Please check your own distribution's package status independently rather than relying solely on this table.

Impact

The immediate consequence of a successful attack is code execution in the context of the process that invokes 7-Zip or p7zip. On a developer workstation, that means: the rights of the logged-in user, bounded by their local permissions – annoying, but usually containable.

The picture gets considerably sharper in automated build and CI/CD environments. A build agent that, as part of a pipeline job, automatically extracts a .tar.xz or .7z release artifact obtained from a third party typically does so unattended, with the credentials and permissions of the pipeline – often including access to secrets, signing keys, cloud credentials, or push rights to artifact repositories and container registries. This is exactly where the formal CVSS classification “local, user interaction required” obscures the real severity: in a CI pipeline, the automated extraction of a downloaded archive is the “user interaction” – just without the possibility of a human first taking a look at the file. A compromised build agent can trigger supply chain fallout that extends far beyond the single machine: tampered artifacts, poisoned container images, leaked signing keys.

Mitigation / Immediate Actions

1. Update to 7-Zip 26.02 or newer

Official download and changelog: https://www.7-zip.org/history.txt and https://www.7-zip.org/. The changelog entry for 26.02 (June 25, 2026) reads tersely: “Some bugs and vulnerabilities were fixed.” – with no explicit CVE mention, underlining the silent nature of the fix.

# Windows: manual download and installation from
# www.7-zip.org/download.html (version 26.02 or newer)
# There is no built-in auto-updater - updating is a manual step.

2. Linux: check package status, don't assume

# Debian/Ubuntu - check installed version
dpkg -l | grep -E '7zip|p7zip'
apt-cache policy 7zip p7zip-full

# Debian (sid/forky carries 26.02+dfsg-2 - fixed; bookworm/trixie
# were still on vulnerable versions at research time)
sudo apt update && sudo apt install --only-upgrade 7zip p7zip-full

# Fedora - check installed version
rpm -q p7zip 7zip
dnf list --installed | grep -E '7zip|p7zip'
# Fedora 44 / Rawhide carried version 25.01-5 at research time
# (within the vulnerable range 21.07-26.01) - verify the update
# status yourself against the Fedora package pages before relying
# on this: packages.fedoraproject.org/pkgs/7zip/7zip/

# Arch Linux - check and update
pacman -Qi 7zip
sudo pacman -Syu 7zip   # extra/7zip already carries 26.02-1 (fixed)

Note: the classic p7zip packages on Debian bullseye/bookworm still carry the old, heavily patched version string 16.02+really26.01+dfsg – “really26.01” indicates that the package content is actually based on 7-Zip 26.01, and therefore still falls within the vulnerable range. For other distributions (openSUSE, Alpine, etc.) no reliable, current package status could be verified as part of this research – please check against your own distro's package database.

3. Harden CI/build pipelines

# Pin the extractor version explicitly instead of implicitly picking
# up "whatever the base image happens to have" at build time.
FROM ci-base:pinned-digest
RUN curl -fsSL www.7-zip.org/... \
    && sha256sum -c 7zip-26.02.sha256   # verify checksum

# Avoid auto-extracting archives from unpinned/unverified sources:
# - only fetch archives from trusted, version-pinned sources
# - verify checksums/signatures of release artifacts before extraction
# - sandbox extraction steps in build pipelines (unprivileged
#   container, no access to secrets during the extract step)
# - where feasible, evaluate alternative extractors (e.g. bsdtar
#   for simple tar.xz cases) instead of 7-Zip in non-interactive pipelines

Detection / Verification

Determine the installed 7-Zip version

# Command line (Windows, Linux, macOS build)
7z --help
7z i          # shows, among other things, the program version in the output

# Windows GUI: 7-Zip File Manager -> Help -> About 7-Zip
# shows the installed version number

Search CI pipeline definitions for 7z/p7zip usage

# Search the repository for calls to 7z/7za/p7zip in pipeline definitions
grep -RniE '\b(7z|7za|7zr|p7zip)\b' \
  .github/workflows .gitlab-ci.yml Jenkinsfile Dockerfile* \
  azure-pipelines.yml .circleci/config.yml 2>/dev/null

# Search build scripts for archive extraction steps
grep -RniE '\.(7z|xz|tar\.xz)\b.*(extract|expand|-x |x )' \
  scripts/ build/ ci/ 2>/dev/null

The goal is a complete list of every place in your own toolchain where 7-Zip or p7zip processes XZ, .7z, or .tar.xz archives – including base images where the extractor version isn't pinned explicitly but is implicitly picked up from the respective package repository.

Recommendation for Operators

Operational decision guide:

• Act this cycle if CI/build systems automatically extract archives from the internet or third parties, and a 7-Zip/p7zip version in the range 21.07–26.01 is in use.
• Verifying only is sufficient if you're already consistently on 7-Zip 26.02 or newer, or if 7-Zip/p7zip is only ever used for self-generated, trusted archives.

Mid-market companies

Check which internal tools (backup scripts, deployment packages, internal file shares) use 7-Zip for extraction. In most cases a regular software update in the next patch window is sufficient; an emergency maintenance window is not strictly necessary given the absence of active exploitation.

Enterprise CI

Inventory build agent images and extractor versions, raise the pinned 7-Zip/p7zip version to 26.02+, and generally check whether extraction steps in pipelines can run with reduced privileges and without access to production secrets. This incident is a good occasion to question the general practice of “auto-extracting third-party artifacts without review.”

Individual developers

Update to 26.02+ once, then your regular update routine is enough. No reason to rush, but also no reason to forget it.

What I Actually Did

I searched my own build and CI configurations (GitHub Actions workflows, Dockerfiles, deploy scripts) for calls to 7z/7za/p7zip. Result: two places use 7-Zip in build containers to extract third-party release artifacts, both times via a base image whose package version wasn't explicitly pinned. I updated the affected Dockerfiles so that the 7-Zip/p7zip version is explicitly pinned to ≥ 26.02 and the base image checksum is fixed, instead of implicitly picking up whatever package version “apt-get install” resolves to at build time. I'm also testing whether the extraction step can be isolated into its own privilege-reduced build stage that has no access to deployment secrets.

Conclusion

CVE-2026-14266 is a good teaching example of how CVSS base scores and real-world urgency can diverge. Formally, it's “just” a local vulnerability requiring user interaction with a CVSS of 7.0 – not a crisis. Practically, though, it hits a very real and often overlooked attack surface: automated build and CI pipelines that extract third-party archives without review, with no human ever looking at them. The silent fix in 26.02, followed by CVE documentation only weeks later, also shows that version tracking matters more than pure CVE feed monitoring – anyone waiting only for official advisories is, in effect, behind reality. The concrete recommendation is unspectacular: update 7-Zip/p7zip to 26.02+, verify package status per distribution, and generally harden extraction steps in CI/build pipelines – independent of this one CVE.

Sources

• The Hacker News: New 7-Zip Vulnerability Could Let Crafted XZ Archives Run Code During Extraction (July 20, 2026)
• Rescana: CVE-2026-14266 – Critical 7-Zip XZ Archive Decoder Vulnerability
• 7-Zip official changelog (history.txt) – entry for version 26.02
• NVD entry for CVE-2026-14266 (status: RESERVED, no full entry as of this writing)
• Debian Security Tracker: CVE-2026-14266
• Fedora Packages: 7zip
• Arch Linux Package: extra/7zip
• Positive Technologies dbugs: CVE-2026-14266 entry