7-Zip CVE-2026-48095: Kritische RCE-Lücke geschlossen

Überblick: Heap-Overflow im NTFS-Handler

Am 22. Mai 2026 hat das GitHub Security Lab das Advisory GHSL-2026-140 zu einer kritischen Schwachstelle in 7-Zip veröffentlicht. CVE-2026-48095 beschreibt einen heap-basierten Pufferüberlauf im NTFS-Archive-Handler von 7-Zip 26.00, der laut Advisory durch eine fehlerhafte Pufferberechnung in der Funktion CInStream::GetCuSize() ausgelöst wird. Der CVSS-3.1-Score liegt bei 8.8 (Hoch) – die Lücke ermöglicht Remote Code Execution durch das bloße Öffnen einer manipulierten Datei.

Entdeckt wurde die Lücke von Jaroslav Lobačevski (GHSL-Team-Mitglied „@JarLob“). In ihrer Mitteilung erklärt das GitHub Security Lab, dass eine speziell präparierte NTFS-Image-Datei dazu führt, dass im Code-Pfad ein Schiebeoperator mit Exponent 32 ausgeführt wird. Das löst Undefined Behavior in C++ aus und reserviert nur 1 Byte statt mehrerer Hundert Megabyte. In diesen 1-Byte-Puffer schreibt 7-Zip anschließend bis zu 256 MB Angreifer-kontrollierten Daten – ein klassischer Heap-Overflow mit direkter Wirkung auf benachbarte Objekte.

Technische Analyse: Vom Shift zum vtable-Hijack

Laut GHSL-2026-140 entsteht der Bug in folgender Berechnung der Compression-Unit-Größe: (UInt32)1 << (BlockSizeLog + CompressionUnit). Der NTFS-Parser akzeptiert Cluster-Größen bis 2^30 Byte. Ein Angreifer wählt im manipulierten NTFS-Image ClusterSizeLog ≥ 28 kombiniert mit CompressionUnit == 4. Damit erreicht der Shift-Exponent den Wert 32, was bei einem 32-Bit-Datentyp Undefined Behavior nach C++-Standard ist.

// CInStream::GetCuSize() in der NTFS-Handler-Implementierung
UInt32 GetCuSize() {
    // BlockSizeLog wird aus Cluster-Size-Log abgeleitet (>= 28 möglich)
    // CompressionUnit ist im NTFS-Compressed-Attribute frei wählbar (bis 4)
    // Bei BlockSizeLog=28 und CompressionUnit=4 ergibt sich Exponent 32.
    return (UInt32)1 << (BlockSizeLog + CompressionUnit);  // UB bei >= 32
}

// Folge: _inBuf wird auf x86/x64 zu 1 Byte allokiert.
// Anschliessend liest 7-Zip 256 MB komprimierte Cluster-Daten in _inBuf.

Das GitHub Security Lab beschreibt die Exploitation-Kette präzise: Bereits nach den ersten 304 Byte der Überschreitung wird der vtable-Pointer eines benachbart allokierten CInStream-Objekts überschrieben. Beim zweiten Read()-Aufruf dispatcht das Programm über den korrupten Pointer – ein lehrbuchmässiger vtable-Hijack. Der Angreifer erhält damit Kontrolle über den Instruction-Pointer.

Angriffsfläche: Jede Dateiendung ist gefährlich

Besonders heimtückisch macht CVE-2026-48095 das MIME-Magic-Verhalten von 7-Zip. Die Software erkennt Archive nicht ausschliesslich anhand der Dateiendung, sondern fällt auf eine signaturbasierte Erkennung zurück, wenn der registrierte Handler die Datei ablehnt. Der NTFS-Handler reagiert auf die Signatur "NTFS " ab Byte-Offset 3 – unabhängig davon, ob die Datei .7z, .zip, .rar oder gar keine Endung trägt.

Für die Angriffsbedingung „User Interaction Required“ (UI:R im CVSS-Vektor) genügt also bereits ein normaler Doppelklick auf eine vermeintlich harmlose Archivdatei. In Kombination mit Phishing-Mailings, Cloud-Sharing-Links und manipulierten Download-Portalen ist die Hürde für einen erfolgreichen Angriff niedrig.

Auswirkungen: Wer ist betroffen?

7-Zip ist mit geschätzten Hunderten Millionen Installationen eines der am weitesten verbreiteten Archivierungs-Tools weltweit – sowohl auf Privat- als auch auf Unternehmens-Endpoints, eingebettet in Software-Distributionen und als Bibliothek in Drittprodukten. Die folgende Übersicht fasst die direkt betroffenen Konstellationen zusammen.

Empfohlene Massnahmen

Die Behebung der Lücke ist trivial – 7-Zip 26.01 vom 27. April 2026 enthält den Fix. Komplex ist hingegen das vollständige Auffinden aller Installationen. Folgende vier Schritte bilden eine pragmatische Reaktion ab:

# Lokale Installationen aus der Registry ausgeben
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Where-Object { $_.DisplayName -like "*7-Zip*" } |
  Select-Object DisplayName, DisplayVersion, InstallLocation

# Beispielausgabe:
# DisplayName     DisplayVersion  InstallLocation
# -----------     --------------  ---------------
# 7-Zip 26.00     26.00           C:\Program Files\7-Zip\

# Remote-Abfrage über mehrere Hosts (Inventarisierung)
$hosts = Get-Content .\inventory.txt
Invoke-Command -ComputerName $hosts -ScriptBlock {
  (Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*).
    Where({ $_.DisplayName -like "*7-Zip*" }) |
    Select-Object DisplayName, DisplayVersion
} | Export-Csv -NoTypeInformation -Path 7zip_audit.csv

Einordnung: Lehren für das Vulnerability Management

CVE-2026-48095 ist aus drei Gründen exemplarisch für die aktuelle Bedrohungslage rund um Standard-Tools: erstens die enorme Verbreitung der betroffenen Software, zweitens die niedrige Eintrittshürde (Doppelklick reicht) und drittens der verfügbare Proof-of-Concept, der die Zeit bis zur Massenausnutzung deutlich verkürzt. Laut GHSL-Timeline wurde die Lücke am 24. April 2026 gemeldet und bereits am 27. April – nach nur drei Tagen – mit 7-Zip 26.01 behoben. Der Hersteller-Reaktionsweg war damit vorbildlich kurz, doch die anschliessende Disclosure am 22. Mai bedeutet, dass Verteidiger seither in einem aktiven Zeitfenster operieren.

Für Sicherheitsverantwortliche bedeutet das konkret: 7-Zip gehört in jede Inventur und in jeden Patch-Zyklus – und zwar nicht nur auf den primären Arbeitsstationen, sondern auch auf Build-Servern, Forensik-Workstations, Mailgateways und Backup-Hosts. Die Frage „Wo läuft bei uns 7-Zip 26.00?“ sollte sich innerhalb weniger Stunden beantworten lassen. Wer sie heute nicht beantworten kann, hat ein strukturelles Problem im Asset- und Schwachstellenmanagement, das CVE-2026-48095 nur sichtbar macht.