7-Zip und PeaZip unter der Lupe: wer dahintersteht, wie sie arbeiten und was drinsteckt

7-Zip steckt auf nahezu jedem dienstlichen Windows-Rechner. Die IT installiert es „für alle Fälle“, die Hälfte der Programme, die ein Update-Paket entpacken müssen, bringt eine eigene Kopie mit, und Anwender „verschlüsseln“ damit Dateien, bevor sie sie per E-Mail verschicken. Genau deshalb lohnt es sich zu wissen, woher es stammt, wie es aufgebaut ist und wo seine Schwachstellen liegen — und was man bekommt, wenn man auf PeaZip umsteigt.

Wer hinter 7-Zip steht

7-Zip hat Igor Pawlow (Igor Pavlov) geschrieben — ein russischer Programmierer — und entwickelt es seit dem ersten Tag. Die erste Fassung erschien 1999, und mehr als ein Vierteljahrhundert später ist das Programm praktisch ein Ein-Personen-Projekt geblieben. Dahinter steht keine Firma, keine Stiftung, kein Team mit verteilten Aufgaben: dieselbe Person schreibt den Code, nimmt Fehlermeldungen entgegen, veröffentlicht Versionen und stellt sie auf 7-zip.org bereit.

Mehrere Eigenschaften dieses Modells sind für die Sicherheit bedeutsam:

• Der Code ist offen, der Prozess nicht. Die Quellen erscheinen als Archive zu jeder Veröffentlichung, unter der GNU LGPL (mit einer zusätzlichen Einschränkung für den RAR-Entpackcode, einzelne Teile unter BSD-Lizenz). Es fehlt jedoch ein öffentliches Repository mit Änderungsverlauf, Code-Review und einer Liste von Personen, die Korrekturen freigeben. Die 7-Zip-Repositories auf GitHub sind Kopien Dritter.
• Die LZMA-Engine ist gemeinfrei. Das LZMA SDK — die Bibliothek mit den Algorithmen LZMA/LZMA2 und der Unterstützung des 7z-Formats — ist in Hunderte anderer Programme, Installer und eingebettete Systeme gewandert. Ein Fehler darin reicht folglich weit über 7-Zip hinaus.
• Ein einziger Vertrauenspunkt. Die Sicherheit von Millionen Installationen hängt von der Redlichkeit, der Gesundheit und der Lage einer einzelnen Person in einer einzigen Jurisdiktion ab. Das ist kein Vorwurf an den Autor — niemand hat eine absichtlich eingebaute Hintertür in 7-Zip nachgewiesen — aber es ist genau die Art von Risiko, die eine Lieferkettenbewertung erfassen soll.

Wie 7-Zip aufgebaut ist

Hinter dem schlichten Fenster steckt eine recht umfangreiche Architektur. Das Programm besteht aus mehreren Dateien, die man leicht verwechselt:

Die Engine ist in C++ und C geschrieben; die heißesten Stellen — der LZMA-Decoder, AES, CRC, SHA — haben zusätzliche Assembler-Fassungen für x86, x64 und ARM64. Im Inneren arbeitet ein Plug-in-System im COM-Stil: jedes Archivformat implementiert Schnittstellen zum Lesen und Schreiben (IInArchive, IOutArchive), jeder Algorithmus eine Coder-Schnittstelle. Ein neues Format anzubauen rührt deshalb den Rest des Programms nicht an.

Das eigene Format 7z ist ein Container: am Anfang ein kurzer Signaturkopf, dann die gepackten Datenströme und am Ende ein Kopf mit der Dateibeschreibung (häufig selbst komprimiert). Dateien lassen sich im Solid-Modus packen — als ein durchgehender Strom — was ein hervorragendes Kompressionsverhältnis liefert, aber bedeutet, dass ein einziges beschädigtes Byte alles Nachfolgende zerstören kann. Zur Verfügung stehen LZMA, LZMA2 (mehrfädig), PPMd, BZip2 und Deflate sowie Filter, die Maschinencode für die Kompression aufbereiten (BCJ, BCJ2, ARM64).

Das Wichtigste aus Sicherheitssicht: 7-Zip erzeugt einige wenige Formate (7z, ZIP, GZIP, BZIP2, XZ, TAR, WIM), liest aber Dutzende — RAR, CAB, ISO, UDF, VHD/VHDX, NTFS- und FAT-Abbilder, HFS, SquashFS, MSI, CHM, NSIS-Installer und viele weitere. Jeder dieser Parser ist Code in einer Sprache ohne Speicherschutz, der Daten verarbeitet, die ein Fremder geliefert hat. Genau dort — und nicht in LZMA selbst — wurden die meisten schwerwiegenden Fehler gefunden.

Wie 7-Zip verschlüsselt

• 7z-Archive: AES-256 im CBC-Modus. Der Schlüssel entsteht aus dem Passwort durch 2¹⁹ (524.288) SHA-256-Iterationen mit Salt. Das bremst das Erraten von Passwörtern vernünftig aus, ist aber keine moderne, GPU-resistente Funktion wie Argon2.
• Keine Authentisierung des Chiffrats. 7z kennt weder einen MAC noch einen AEAD-Modus. Die Integrität prüft eine CRC32 der entpackten Daten — eine Prüfsumme, kein kryptographischer Nachweis, dass niemand etwas verändert hat.
• ZIP-Archive: Standardverfahren ist das alte ZipCrypto, das per Known-Plaintext-Angriff gebrochen wird (Werkzeuge wie bkcrack schaffen das in Minuten, wenn ein Ausschnitt auch nur einer Datei bekannt ist). AES-256 muss man von Hand wählen.

Lecks: was ein „verschlüsseltes“ Archiv verrät

Das häufigste Leck rund um 7-Zip braucht überhaupt keinen Exploit. Die Standardeinstellungen genügen:

1. Dateinamen bleiben im Klartext. In einem passwortgeschützten 7z-Archiv ist die Dateiliste — Namen, Größen, Änderungsdaten — ohne Passwort sichtbar, solange man nicht „Dateinamen verschlüsseln“ ankreuzt (auf der Kommandozeile: -mhe=on). Eine Datei namens Pruefergebnisse_Mueller_Steuernummer.xlsx spricht für sich, auch wenn ihr Inhalt sicher ist. Bei ZIP lassen sich Dateinamen überhaupt nicht verschlüsseln.
2. ZIP mit ZipCrypto. Der Anwender sieht ein Feld „Passwort“ und nimmt an, die Daten seien geschützt. Mit ZipCrypto ist dieser Schutz eine Illusion.
3. Passwort im selben Kanal. Das Archiv im Anhang, das Passwort in der nächsten E-Mail an dasselbe Postfach — das ist ein Problem des Verfahrens, nicht des Programms, aber 7-Zip erschwert es in keiner Weise.
4. Verlust der Markierung „aus dem Internet“. Windows kennzeichnet heruntergeladene Dateien mit dem Mark-of-the-Web, dank dessen SmartScreen und Office vor dem Öffnen warnen. Jahrelang übertrug 7-Zip diese Kennzeichnung gar nicht auf entpackte Dateien; seit Version 22.00 kann es das, doch die Option muss eingeschaltet werden. Die Schwachstelle CVE-2025-0411 erlaubte es, die Markierung selbst bei aktiviertem Schutz zu verlieren — durch ein Archiv im Archiv.

Ein Jahr später versagte derselbe Schutzmechanismus erneut, und zwar gründlicher. CVE-2026-58052 — von einem Forscher unter dem Pseudonym ashdfrkl über VulnCheck gemeldet und am 27. Juni 2026 veröffentlicht — nutzt ein präpariertes RAR5-Archiv. 7-Zip unterdrückte einen im Archiv mitgelieferten Datenstrom mit dem exakten Namen Zone.Identifier, ein RAR5-Eintrag namens :Zone.Identifier:$DATA rutschte jedoch durch dieses Sieb, und NTFS führte beide Namen auf denselben Strom zurück — womit die gerade gesetzte Internetzonen-Markierung mit ZoneId=0 überschrieben wurde. Ein zweiter Eintrag, ::$DATA, ersetzte den eigentlichen Inhalt der entpackten Datei. Ergebnis: keine SmartScreen-Warnung und eine Datei, die etwas anderes zeigt, als ihr Name verspricht. Die NVD führt alle Versionen bis einschließlich 26.01 als betroffen; die Korrektur kam erst mit 26.03 vom 3. September 2026. Ein Proof of Concept ist öffentlich.

Die wichtigsten Schwachstellen des letzten Jahrzehnts

Die folgende Liste ist nicht vollständig, zeigt aber das Muster: die Fehler sitzen überwiegend in den Parsern selten genutzter Formate, und die Folge ist oft Codeausführung schon beim Öffnen eines Archivs.

Die Fehler selbst sind nichts Außergewöhnliches — die hat jeder Archivierer. Das Problem ist, was nach der Veröffentlichung einer Korrektur geschieht:

• 7-Zip aktualisiert sich nicht selbst. Es gibt weder einen Aktualisierungsdienst noch auch nur einen Hinweis auf eine neue Version. In einer typischen Organisation läuft auf jedem Rechner die Version, die am Tag der Systeminstallation aktuell war — mitunter Jahre alt.
• Kopien in fremden Programmen. 7z.dll und 7za.exe liegen in den Verzeichnissen von Dutzenden Anwendungen und Skripten. Eine Aktualisierung des „Haupt“-7-Zip rührt sie nicht an, und eine Inventur solcher Kopien findet in der Praxis nicht statt.
• Keine digitale Signatur. Die Installer von 7-zip.org tragen kein Authenticode-Zertifikat. Eine AppLocker/WDAC-Regel nach dem Muster „Dateien dieses Herausgebers zulassen“ lässt sich also nicht bauen, und der Anwender erkennt das Original nicht an der Signatur von der Fälschung.
• Gefälschte Seiten. Die einzige offizielle Adresse ist 7-zip.org. Täuschend ähnliche Domains dienten wiederholt dazu, Installer mit beigefügter Schadsoftware zu verbreiten — und die fehlende digitale Signatur erleichtert solche Untergriffe.

PeaZip: welche Engine wirklich darin steckt

PeaZip fällt oft als „Alternative zu 7-Zip“. Es stammt von Giorgio Tani aus Italien, entsteht seit 2006 in Free Pascal mit der Umgebung Lazarus und steht unter der LGPLv3. Es läuft unter Windows, Linux und macOS, hat eine modernere Oberfläche und eingebaute Werkzeuge für Prüfsummen, sicheres Löschen und Verzeichnisvergleiche.

Entscheidend ist eine Tatsache, die kaum jemand kennt: PeaZip ist zum großen Teil eine grafische Oberfläche. Selbst erledigt es nur sein eigenes Format PEA; bei allen übrigen Formaten ruft es externe Programme auf, die es im Unterverzeichnis res\bin mitliefert:

• 7-Zip (7z.exe und 7z.dll; unter Linux 7-Zip für Linux oder p7zip) — zuständig für 7z, ZIP, TAR, GZ, XZ, ISO, CAB, das Entpacken von RAR und die meisten übrigen Formate,
• Brotli und Zstandard — die Referenzwerkzeuge dieser Algorithmen,
• FreeArc, ZPAQ und die PAQ-Familie — Formate mit sehr hoher Kompression,
• UPX — Packen ausführbarer Dateien.

Das heißt: Wer in PeaZip ein 7z- oder ZIP-Archiv erstellt oder öffnet, dessen Arbeit erledigt genau derselbe Code wie in 7-Zip. Er erbt sämtliche Schwachstellen von 7-Zip — und erhält Korrekturen erst, wenn der PeaZip-Autor eine neue Fassung mit neuerer 7z.dll veröffentlicht. Was das praktisch bedeutet, steht weiter unten.

Worin sich PeaZip tatsächlich unterscheidet

Das Format PEA ist kryptographisch besser durchdacht als 7z — die authentisierte Verschlüsselung erkennt jede Veränderung des Archivs, nicht nur eine zufällige Beschädigung. Nur öffnet ein PEA-Archiv praktisch ausschließlich PeaZip, sodass man für den Austausch mit Außenstehenden ohnehin zu 7z oder ZIP zurückkehrt — also zu 7-Zip darunter.

Warum polnische Behörden von 7-Zip abgerückt sind

Es gibt keine einzelne öffentliche Verordnung, die 7-Zip verbieten würde. Die Entscheidungen fallen in internen Sicherheitsrichtlinien, Ausschreibungsanforderungen und Listen zugelassener Software — Dokumenten, die nicht veröffentlicht werden. Aus Gesprächen mit Kunden des öffentlichen Sektors ergibt sich jedoch, dass die Argumente sich fast wörtlich wiederholen:

1. Herkunft des Anbieters. Seit 2022 prüfen Institutionen Software aus Russland und Belarus weit genauer, und die Novelle des polnischen Gesetzes über das nationale Cybersicherheitssystem sieht einen Mechanismus zur Einstufung als Hochrisikoanbieter vor. Ein Ein-Personen-Projekt in Russland, ohne Firma, mit der sich ein Vertrag schließen ließe, und ohne Möglichkeit, den Veröffentlichungsprozess zu prüfen, besteht eine solche Bewertung nicht — unabhängig von der Qualität des Codes.
2. Reale Angriffe über Archivierer. CVE-2025-0411 wurde gegen staatliche Einrichtungen eines Nachbarlandes eingesetzt. Für polnische Dienste ist das keine Abstraktion, sondern die Beschreibung eines Angriffs, der sie morgen treffen kann.
3. Keine Kontrolle über Versionen. Ein Programm ohne Aktualisierungsmechanismus und ohne digitale Signatur lässt sich schwer zentral ausrollen, schwer in seinen Versionen verfolgen und schwer per AppLocker/WDAC gegen Fälschungen absichern.
4. Die Kryptographie erfüllt die Anforderungen nicht. AES-CBC ohne Authentisierung, standardmäßig offene Dateinamen und ZipCrypto bei ZIP ergeben eine Zusammenstellung, die keine Prüfung besteht. Für Verschlusssachen taugt ein Archivierer ohnehin nicht: deren Schutz verlangt kryptographische Mittel mit einem Zertifikat der polnischen ABW oder SKW.
5. Lieferkette und SBOM. Auftraggeber verlangen immer häufiger ein Verzeichnis der Softwarebestandteile. Ein in zehn Produkte in zehn verschiedenen Fassungen hineinkopiertes 7-Zip ist ein Posten, den niemand einem Prüfer erklären möchte.

Der Ersatz, zu dem am häufigsten gegriffen wurde, ist PeaZip. Aus Sicht einer solchen Richtlinie ist das eine folgerichtige Wahl: ein Autor aus der Europäischen Union, ein aktiv gepflegtes Repository auf GitHub, berechenbare Veröffentlichungen und ein eigenes Format mit ordentlicher authentisierter Verschlüsselung. Die Institution bekommt einen Anbieter, den sie in ihrer Dokumentation beschreiben kann.

Man sollte allerdings wissen, was man sich damit einkauft. Bei den Formaten 7z und ZIP erledigt weiterhin die beigelegte 7-Zip-Engine die Arbeit, die Schwachstellen in den Parsern bleiben also — es ändert sich, wer die Korrektur wann liefert. Bei PeaZip lohnt es deshalb, auf zweierlei zu achten: dass das Programm aktuell ist (denn mit ihm wird die eingebaute 7z.dll aktualisiert) und dass bei der Softwareinventur auch das erfasst wird, was in seinem Unterverzeichnis res\bin liegt. Vollständige Unabhängigkeit vom 7-Zip-Code bringt erst das Format PEA — das beim Empfänger allerdings ausschließlich PeaZip öffnet.

Was in der Praxis zu tun ist

Wenn 7-Zip vorerst in der Organisation bleiben muss:

• laden Sie es ausschließlich von 7-zip.org und halten Sie mindestens Version 26.03 vom 3. September 2026 — sie behebt die jüngste Umgehung des Mark-of-the-Web; alle älteren haben bekannte, öffentlich beschriebene Schwachstellen,
• rollen Sie es zentral aus und suchen Sie verwaiste Kopien von 7z.dll, 7za.exe und 7zr.exe in den Verzeichnissen anderer Programme,
• verwenden Sie zum Verschlüsseln stets das Format 7z mit eingeschalteter Verschlüsselung der Dateinamen (-mhe=on); muss es ZIP sein — dann nur AES-256, niemals ZipCrypto,
• schalten Sie in den Einstellungen (Extras → Optionen → 7-Zip) die Übernahme des Zone.Identifier auf entpackte Dateien ein,
• übermitteln Sie das Passwort über einen anderen Kanal als das Archiv selbst — telefonisch oder per SMS.

Zum bloßen Entpacken üblicher Archive genügt heute Windows 11: seit der Aktualisierung vom Herbst 2023 öffnet der Explorer 7z, RAR und TAR über die eingebaute Bibliothek libarchive, ganz ohne Installation.

Quellen

• Offizielle 7-Zip-Seite und Änderungsverlauf: 7-zip.org, 7-zip.org/history.txt, Lizenz: 7-zip.org/license.txt
• LZMA SDK: 7-zip.org/sdk.html
• PeaZip: peazip.github.io
• Schwachstellenbeschreibungen in der NVD: CVE-2026-58052, CVE-2025-0411, CVE-2025-11001, CVE-2025-55188, CVE-2024-11477, CVE-2018-10115
• Beschreibung der Mark-of-the-Web-Lücke in RAR5: VulnCheck-Meldung