7-Zip CVE-2026-14266: Heap-Out-of-Bounds-Write im XZ-Decoder (MixCoder_Code) – Versionen 21.07 bis 26.01 betroffen

TL;DR — 90 Sekunden

Betroffen?

7-Zip 21.07 bis 26.01 (Windows-Builds von 7-zip.org) sowie alle Linux-Pakete (p7zip, distro-eigene 7zip-Pakete), die intern auf einer dieser Versionen basieren. Konkret betroffen ist jeder Prozess, der mit einer verwundbaren 7-Zip-Version ein XZ-, .7z- oder .tar.xz-Archiv entpackt – inklusive automatisierter Build- und CI-Jobs.

Risiko?

Heap-Out-of-Bounds-Write im XZ-Decoder (MixCoder_Code, C/XzDec.c), auslösbar durch ein präpariertes Archiv. CVSS 3.0 7.0 (AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H) laut sekundärer Bewertung (Rescana) – lokaler Angriffsvektor, Nutzerinteraktion erforderlich, keine erhöhten Rechte nötig. Der NVD-Eintrag steht zum Zeitpunkt dieses Beitrags noch auf RESERVED, ein offiziell bestätigter CVSS-Vektor liegt also nicht vor.

Sofortmaßnahme?

Kein Fire-Drill: kein öffentlicher Exploit, keine bekannte aktive Ausnutzung. Aber: Build- und CI-Pipelines, die 7-Zip/p7zip zum automatisierten Entpacken von Drittanbieter-Archiven einsetzen, sollten zeitnah auf 26.02 oder neuer prüfen und aktualisieren.

Empfehlung?

Diesen Zyklus handeln, wenn CI-/Build-Systeme ungeprüfte Archive automatisiert entpacken. Nur verifizieren reicht, wenn bereits 26.02+ im Einsatz ist oder 7-Zip nicht für nicht vertrauenswürdige Eingaben genutzt wird.

Kritikalität?

medium — lokaler Vektor, Nutzerinteraktion nötig, kein PoC, keine Exploitation in the wild, aber breiter Versionsbereich (fast 5 Jahre) und relevante Angriffsfläche in automatisierten Build-Pipelines, wo das automatische Entpacken selbst die „Nutzerinteraktion“ im Sinne der CVSS-Metrik darstellen kann.

Was ist das Problem?

7-Zip nutzt für das XZ-Format (und darauf aufbauende Container wie .7z mit LZMA2-Streams oder .tar.xz) einen eigenen Decoder in C/XzDec.c. Kernstück ist die Funktion MixCoder_Code, die den eigentlichen Dekomprimierungs-Loop über mehrere Durchläufe (Passes) steuert und dabei Daten in einen vom Aufrufer bereitgestellten Ausgabepuffer schreibt.

Der Fehler: Bei jedem einzelnen Dekomprimierungsdurchlauf übergab der Code dem Decoder die vollständige Länge des Ausgabepuffers – nicht die tatsächlich noch verfügbare, verbleibende Kapazität nach den bereits in vorherigen Durchläufen geschriebenen Bytes. Bei einem regulären, wohlgeformten Archiv fällt das nicht auf, weil Ein- und Ausgabemenge zueinander passen. Wird der Datenstrom jedoch gezielt so präpariert, dass mehrere Durchläufe hintereinander jeweils erneut die volle Puffergröße „sehen“, schreibt der Decoder bei jedem weiteren Pass über das Ende des tatsächlich noch freien Speicherbereichs hinaus – ein klassischer Heap-Out-of-Bounds-Write. Je nach Heap-Layout, Allocator und angrenzenden Strukturen kann das von einem Absturz bis zu kontrollierter Codeausführung reichen.

Bemerkenswert ist der Offenlegungs-Zeitstrahl: 7-Zip-Maintainer Igor Pavlov hat den Bug offenbar bereits mit Version 26.02 am 25. Juni 2026 stillschweigend behoben – der Changelog-Eintrag nennt lediglich pauschal „Some bugs and vulnerabilities were fixed“, ohne CVE-Referenz oder Sicherheitshinweis. Erst rund drei bis vier Wochen später, am 15. bzw. 20. Juli 2026, wurde die Lücke über eine ZDI-Advisory und anschließende Sekundärberichterstattung öffentlich mit CVE-2026-14266 verknüpft und dokumentiert. Dieses Muster – stiller Fix in einem Punktrelease, nachträgliche CVE-Zuordnung Wochen später – ist bei 7-Zip kein Einzelfall: Pavlov behebt Sicherheitsprobleme regelmäßig ohne begleitende Advisory, was bedeutet, dass reines „Release Notes lesen“ kein verlässlicher Sicherheitsprozess ist. Wer sich ausschließlich auf CVE-Feeds statt auf Versions-Diffs verlässt, hängt der Realität im Zweifel Wochen hinterher.

Wer ist betroffen?

Der verwundbare Codepfad steckt im gemeinsamen 7-Zip-C-Quellcode und wirkt sich dadurch auf mehrere Distributionskanäle unterschiedlich aus:

Wichtiger Hinweis zur Transparenz: Für weitere Distributionen (z. B. openSUSE, Alpine sowie kommerzielle Linux-Derivate) konnte im Rahmen dieser Recherche keine verlässliche, aktuelle Paketversion verifiziert werden. Bitte den Paketstatus der eigenen Distribution eigenständig prüfen, statt sich auf diese Tabelle allein zu verlassen.

Auswirkungen

Die unmittelbare Folge eines erfolgreichen Angriffs ist Codeausführung im Kontext des Prozesses, der 7-Zip bzw. p7zip aufruft. Auf einer Entwickler-Workstation heißt das: Rechte des angemeldeten Nutzers, begrenzt durch dessen lokale Berechtigungen – ärgerlich, aber meist eingrenzbar.

Deutlich schärfer wird das Bild in automatisierten Build- und CI/CD-Umgebungen. Ein Build-Agent, der im Rahmen eines Pipeline-Jobs ein von einem Drittanbieter bezogenes .tar.xz- oder .7z-Release-Artefakt automatisch entpackt, tut dies typischerweise unbeaufsichtigt, mit den Zugangsdaten und Berechtigungen der Pipeline – oft inklusive Zugriff auf Secrets, Signierschlüssel, Cloud-Credentials oder Push-Rechte auf Artefakt-Repositories und Container-Registries. Genau hier verwischt die formale CVSS-Einstufung „lokal, Nutzerinteraktion erforderlich“ die reale Brisanz: In einer CI-Pipeline ist das automatisierte Entpacken eines heruntergeladenen Archivs die „Nutzerinteraktion“ – nur eben ohne die Möglichkeit, dass vorher ein Mensch einen Blick auf die Datei wirft. Ein kompromittierter Build-Agent kann Supply-Chain-Folgeschäden auslösen, die weit über die einzelne Maschine hinausreichen: manipulierte Artefakte, vergiftete Container-Images, abgeflossene Signierschlüssel.

Mitigation / Sofortmaßnahmen

1. Auf 7-Zip 26.02 oder neuer aktualisieren

Offizieller Download und Changelog: https://www.7-zip.org/history.txt sowie https://www.7-zip.org/. Der Changelog-Eintrag zu 26.02 (25. Juni 2026) lautet knapp: „Some bugs and vulnerabilities were fixed.“ – ohne explizite CVE-Nennung, was den stillen Charakter des Fixes unterstreicht.

# Windows: manueller Download und Installation von
# www.7-zip.org/download.html (Version 26.02 oder neuer)
# Es gibt keinen integrierten Auto-Updater - Aktualisierung ist manuell noetig.

2. Linux: Paketstatus prüfen statt blind vertrauen

# Debian/Ubuntu - installierte Version pruefen
dpkg -l | grep -E '7zip|p7zip'
apt-cache policy 7zip p7zip-full

# Debian (sid/forky fuehrt 26.02+dfsg-2 - behoben; bookworm/trixie
# waren zum Recherchezeitpunkt noch auf verwundbaren Versionen)
sudo apt update && sudo apt install --only-upgrade 7zip p7zip-full

# Fedora - installierte Version pruefen
rpm -q p7zip 7zip
dnf list --installed | grep -E '7zip|p7zip'
# Fedora 44 / Rawhide fuehrten zum Recherchezeitpunkt Version 25.01-5
# (innerhalb des verwundbaren Bereichs 21.07-26.01) - Update-Status
# vor dem Lesen dieses Beitrags eigenstaendig gegen die Fedora-
# Paketseiten pruefen: packages.fedoraproject.org/pkgs/7zip/7zip/

# Arch Linux - Version pruefen und aktualisieren
pacman -Qi 7zip
sudo pacman -Syu 7zip   # extra/7zip fuehrt bereits 26.02-1 (behoben)

Hinweis: Für die klassischen p7zip-Pakete unter Debian bullseye/bookworm gilt weiterhin die alte, stark gepatchte Versionsnummer 16.02+really26.01+dfsg – „really26.01“ zeigt, dass der Paket-Inhalt inhaltlich auf 7-Zip 26.01 beruht und damit ebenfalls im verwundbaren Bereich liegt. Für weitere Distributionen (openSUSE, Alpine u. a.) konnte im Rahmen dieser Recherche kein verlässlicher, aktueller Paketstatus verifiziert werden – bitte selbst gegen die jeweilige Distro-Paketdatenbank prüfen.

3. CI/Build-Pipelines härten

# Extractor-Version explizit pinnen statt "immer aktuellstes Paket"
# implizit ueber das Basis-Image zu beziehen.
FROM ci-base:pinned-digest
RUN curl -fsSL www.7-zip.org/... \
    && sha256sum -c 7zip-26.02.sha256   # Checksumme verifizieren

# Auto-Extraktion von unpinned/unverifizierten Quellen vermeiden:
# - Archive nur aus vertrauenswuerdigen, versionsgepinnten Quellen beziehen
# - Checksums/Signaturen von Release-Artefakten vor dem Entpacken pruefen
# - Entpack-Schritte in Build-Pipelines sandboxen (unprivilegierter
#   Container, kein Zugriff auf Secrets waehrend des Extract-Schritts)
# - Wo moeglich: alternative Entpacker (z. B. bsdtar fuer einfache
#   tar.xz-Faelle) statt 7-Zip in nicht interaktiven Pipelines evaluieren

Detection / Prüfung

Installierte 7-Zip-Version ermitteln

# Kommandozeile (Windows, Linux, macOS-Build)
7z --help
7z i          # zeigt u.a. die Programmversion in der Ausgabe

# Windows GUI: 7-Zip File Manager -> Hilfe -> Ueber 7-Zip
# zeigt die installierte Versionsnummer an

CI-Pipeline-Definitionen auf 7z/p7zip-Nutzung durchsuchen

# Repository-weit nach Aufrufen von 7z/7za/p7zip in Pipeline-Definitionen suchen
grep -RniE '\b(7z|7za|7zr|p7zip)\b' \
  .github/workflows .gitlab-ci.yml Jenkinsfile Dockerfile* \
  azure-pipelines.yml .circleci/config.yml 2>/dev/null

# In Build-Skripten nach Archiv-Extraktionsschritten suchen
grep -RniE '\.(7z|xz|tar\.xz)\b.*(extract|entpack|expand|-x |x )' \
  scripts/ build/ ci/ 2>/dev/null

Ziel ist eine vollständige Liste aller Stellen, an denen 7-Zip oder p7zip in der eigenen Toolchain XZ-, .7z- oder .tar.xz-Archive verarbeitet – inklusive Basis-Images, in denen die Extraktor-Version nicht explizit gepinnt, sondern implizit über das jeweilige Paketrepository bezogen wird.

Betreiberempfehlung

Operative Entscheidungshilfe:

• Diesen Zyklus handeln, wenn CI-/Build-Systeme automatisiert Archive aus dem Internet oder von Drittanbietern entpacken und dabei eine 7-Zip/p7zip-Version im Bereich 21.07–26.01 zum Einsatz kommt.
• Nur verifizieren reicht, wenn bereits durchgängig 7-Zip 26.02 oder neuer im Einsatz ist, oder wenn 7-Zip/p7zip ausschließlich für selbst erzeugte, vertrauenswürdige Archive genutzt wird.

Mittelstand

Prüfen, welche internen Tools (Backup-Skripte, Deployment-Pakete, interne Fileshares) 7-Zip zum Entpacken nutzen. Meist reicht ein reguläres Software-Update im nächsten Patch-Fenster; ein Notfall-Wartungsfenster ist angesichts fehlender aktiver Ausnutzung nicht zwingend nötig.

Enterprise-CI

Build-Agent-Images und Extractor-Versionen inventarisieren, gepinnte 7-Zip/p7zip-Version auf 26.02+ anheben, und grundsätzlich prüfen, ob Extraktionsschritte in Pipelines mit reduzierten Rechten und ohne Zugriff auf Produktions-Secrets laufen können. Dieser Vorfall ist ein guter Anlass, die generelle Praxis „Drittanbieter-Artefakte ungeprüft automatisiert entpacken“ zu hinterfragen.

Einzelentwickler

Einmalig auf 26.02+ aktualisieren, danach reicht die reguläre Update-Routine. Kein Grund zur Eile, aber auch kein Grund, es zu vergessen.

Was ich konkret getan habe

Ich habe meine eigenen Build- und CI-Konfigurationen (GitHub Actions Workflows, Dockerfiles, Deploy-Skripte) nach Aufrufen von 7z/7za/p7zip durchsucht. Ergebnis: An zwei Stellen wird 7-Zip in Build-Containern zum Entpacken von Drittanbieter-Release-Artefakten verwendet, beide Male über ein Basis-Image, dessen Paketversion nicht explizit gepinnt war. Ich habe die betroffenen Dockerfiles so angepasst, dass die 7-Zip/p7zip-Version explizit auf einen Stand ≥ 26.02 gepinnt und die Checksumme des Basis-Images fixiert wird, statt sie implizit über „apt-get install“ auf den zum Build-Zeitpunkt aktuellen Paketstand zu beziehen. Zusätzlich prüfe ich testweise, ob sich der Entpack-Schritt in einer eigenen, rechte-reduzierten Build-Stage isolieren lässt, die keinen Zugriff auf Deployment-Secrets hat.

Fazit

CVE-2026-14266 ist ein gutes Lehrbeispiel dafür, dass CVSS-Basiswerte und reale Dringlichkeit auseinanderfallen können. Formal ist es „nur“ eine lokale Schwachstelle mit Nutzerinteraktion und CVSS 7.0 – keine Krisensituation. Praktisch trifft sie aber eine sehr reale und oft übersehene Angriffsfläche: automatisierte Build- und CI-Pipelines, die Drittanbieter-Archive ungeprüft entpacken, ohne dass je ein Mensch draufschaut. Der stille Fix in 26.02, gefolgt von einer CVE-Dokumentation erst Wochen später, zeigt zudem, dass Versions-Tracking wichtiger ist als reines CVE-Feed-Monitoring – wer nur auf offizielle Advisories wartet, hinkt der Realität hinterher. Die konkrete Handlungsempfehlung ist unspektakulär: 7-Zip/p7zip auf 26.02+ aktualisieren, Paketstatus je Distribution verifizieren, und in CI-/Build-Pipelines Extraktionsschritte grundsätzlich härten – unabhängig von dieser einzelnen CVE.

Quellen

• The Hacker News: New 7-Zip Vulnerability Could Let Crafted XZ Archives Run Code During Extraction (20. Juli 2026)
• Rescana: CVE-2026-14266 – Critical 7-Zip XZ Archive Decoder Vulnerability
• 7-Zip offizieller Changelog (history.txt) – Eintrag zu Version 26.02
• NVD-Eintrag zu CVE-2026-14266 (Stand: RESERVED, kein vollständiger Eintrag zum Zeitpunkt dieses Beitrags)
• Debian Security Tracker: CVE-2026-14266
• Fedora Packages: 7zip
• Arch Linux Package: extra/7zip
• Positive Technologies dbugs: CVE-2026-14266 Eintrag