Jaroslav Lobačevski z GitHub Security Lab opublikował analizę nowej podatności odnalezionej w 7-Zip, oznaczonej jako GHSL-2026-140. Luka dotyczy parsera NTFS i prowadzi do uszkodzenia pamięci procesu, co w określonych warunkach może stworzyć możliwość wykonania kodu po stronie ofiary.

Autor: 6 min czytania

Wykryty błąd może zostać wykorzystany w scenariuszu prowadzącym do tzw. vtable hijacking, a więc przejęcia kontroli nad przepływem wykonywania programu. Nie oznacza to jednak łatwego do powtórzenia exploita. Od wykrycia memory corruption do przygotowania stabilnego łańcucha prowadzącego do RCE zwykle droga jest długa.

Analiza podatności

Podatność dotyczy sposobu, w jaki 7-Zip obsługuje NTFS compressed streams, czyli mechanizm wykorzystywany w systemie plików NTFS do przechowywania skompresowanych danych.

Źródłem problemu jest błędne obliczanie rozmiaru bufora pamięci wykorzystywanego do przetwarzania takich danych.

W uproszczeniu aplikacja wylicza rozmiar potrzebnego bufora na podstawie dwóch parametrów: BlockSizeLog oraz CompressionUnit, odczytywanych z analizowanego archiwum.

(UInt32)1 << (BlockSizeLog + CompressionUnit)

Problem pojawia się w przypadku specjalnie spreparowanych danych wejściowych, gdy parametry przyjmują wartości ClusterSizeLog >= 28 oraz CompressionUnit = 4.

Taka konfiguracja prowadzi do próby przesunięcia 32-bitowej wartości o 32 pozycje, co skutkuje niezdefiniowanym zachowaniem w C++. W rezultacie błędnego wyliczenia dla bufora zostaje zaalokowany raptem 1 bajt pamięci.

Następnie 7-Zip próbuje zapisać do bufora o rozmiarze 1 bajta aż 256 MB danych, które mogą być kontrolowane przez atakującego.

To klasyczny przykład heap buffer overflow, czyli zapisu danych poza granicami zaalokowanego obszaru pamięci.

Jak heap buffer overflow może zostać wykorzystany do ataku

Heap overflow najczęściej kończy się crashem aplikacji. Problem zaczyna się wtedy, gdy da się kontrolować to, co zostaje nadpisane.

W takim scenariuszu odpowiednio spreparowany plik może stworzyć realne ryzyko zdalnego wykonania kodu.

Kluczowym element podatności jest to, co następuje później. Analiza GitHub Security Lab wykazała, że zaledwie 304 bajty dalej od wcześniej przydzielonego bufora znajduje się obiekt CInStream.

Mechanizm zapisu danych działa w pętli. Funkcja ReadStream_FALSE() zapisuje dane w blokach po 64 KB. Oznacza to, że już podczas pierwszego zapisu dochodzi do nadpisania obiektu CInStream, a wraz z nim również jego wskaźnika vtable.

Żeby zrozumieć, dlaczego jest to groźne, trzeba wyjaśnić jedną rzecz: czym właściwie jest vtable. Vtable to wykorzystywana w C++ tablica przechowująca adresy funkcji wirtualnych danego obiektu. Obiekt wskazuje na vtable, vtable wskazuje na właściwą funkcję, a program wykonuje oczekiwany kod.

Jeśli napastnik nadpisze wskaźnik vtable, może przejąć kontrolę nad tym, jaki kod zostanie wykonany przy kolejnym wywołaniu metody wirtualnej. To właśnie klasyczny vtable hijacking – technika, która wielokrotnie pojawiała się w exploitach dla aplikacji C++.

Warto podkreślić, że problem nie dotyczy wyłącznie wersji x86, ale również x64. Nawet w architekturze 64-bitowej 7-Zip wykonuje problematyczne obliczenie na 32-bitowej wartości (UInt32), dlatego błąd pozostaje aktualny. Dodatkowym ograniczeniem pozostaje konieczność obsługi bardzo dużych alokacji pamięci, co może utrudnić praktyczne wykorzystanie luki na części systemów, ale nie eliminuje scenariusza exploita.

Czy problem dotyczy wyłącznie NTFS?

Na początku zaznaczyliśmy, że problem dotyka parsera NTFS i faktycznie domyślnie jest on powiązany wyłącznie z rozszerzeniami .ntfs oraz .img. Podatność jednak nie ogranicza się do tych rodzajów plików, ponieważ 7-Zip nie bazuje wyłącznie na rozszerzeniu pliku.

Jeżeli parser przypisany do danego typu pliku nie rozpozna poprawnej struktury, uruchamiany jest mechanizm dodatkowej analizy, który dopasowuje format na podstawie tzw. magic bytes. Są to charakterystyczne ciągi znaków umieszczone w określonych miejscach pliku, pozwalające rozpoznać jego rzeczywisty format.

W przypadku parsera NTFS identyfikatorem jest ciąg znaków „NTFS” umieszczony pod określonym offsetem w strukturze pliku.

Oznacza to, że odpowiednio spreparowany obraz NTFS może zostać obsłużony przez podatny parser nawet wtedy, gdy otrzyma typowe dla archiwów rozszerzenie, takie jak .zip, .7z czy .rar.

O ile plik z rozszerzeniem .ntfs może wzbudzić czujność, o tyle archiwum .zip będzie dla większości użytkowników wyglądać zupełnie niepozornie.

Poprzednio opisane podatności w 7-Zip

To nie pierwsza podatność związana z 7-Zip, jaką opisywaliśmy na Kapitanie. Wcześniej informowaliśmy m.in. o luce CVE-2025-11001 oraz o podatności umożliwiającej obejście części mechanizmów ochronnych:

Jak błąd w 7-Zip (CVE-2025-11001) daje hakerom dostęp do systemu Windows. Jest exploit

Podatność w 7-Zipie umożliwia zdalnym atakującym ominięcie zabezpieczeń i wykonanie dowolnego kodu

Wpływ podatności i rekomendowane działania

Opisana w tym artykule podatność otrzymała ocenę CVSS 8.8. Wysoka ocena wynika przede wszystkim z możliwości zdalnego dostarczenia spreparowanego pliku, braku konieczności posiadania wcześniejszych uprawnień oraz potencjalnie wysokiego wpływu na poufność, integralność i dostępność systemu w przypadku skutecznego wykorzystania.

Warto jednak pamiętać, że wysoki wynik CVSS nie oznacza automatycznie łatwej exploitacji. W tym przypadku droga od kontrolowanego przepełnienia pamięci do stabilnego, powtarzalnego exploita jest złożona technicznie i wymaga spełnienia szeregu dodatkowych warunków.

Podatność dotyczy wszystkich wersji 7-Zip do 26.00 włącznie. Problem został usunięty w wersji 26.01, dlatego podstawowym zaleceniem pozostaje aktualizacja do najnowszego wydania. Nawet jeśli praktyczne wykorzystanie luki nie należy do trywialnych, parsery przetwarzające nieufne dane zawsze stanowią atrakcyjny cel ataku, dlatego odkładanie aktualizacji nie jest dobrym pomysłem.