Wirtualizacja / DATA PUBLICZNEGO OGŁOSZENIA
Zapscape: ucieczka z maszyny KVM na hosta
Luka w KVM/x86 mogła pozwolić napastnikowi wydostać się z maszyny wirtualnej i zaatakować serwer, na którym działała.
Co się wydarzyło?
Rekord CVE-2026-64561 opublikowano 4 sierpnia 2026 roku. Dwa dni później Hyunwoo Kim przedstawił raport Zapscape na liście oss-security. Opisał błąd use-after-free w obsłudze pamięci KVM/x86: wykorzystanie obiektu po zwolnieniu mogło naruszyć granicę między maszyną wirtualną a hostem.
Szczególne znaczenie miały środowiska uruchamiające niezaufane maszyny i udostępniające wirtualizację zagnieżdżoną, czyli możliwość uruchamiania kolejnych maszyn wewnątrz gościa. Warunki wykorzystania różniły się między platformami Intel i AMD.
Dlaczego to ważne dla hostingu?
Kontrola nad systemem gościa nie powinna dawać kontroli nad fizycznym serwerem. Przekroczenie tej granicy może zagrozić również innym usługom działającym na hoście. To problem warstwy wirtualizacji, więc aktualizacja CMS ani samego systemu wewnątrz VPS nie zastępuje naprawy hosta.
Poprawki i sprawdzenie zagrożonego serwera
Istotna jest wersja jądra uruchomiona na hoście oraz poprawki jego dostawcy. Debian wskazuje historyczną poprawkę dla trixie w pakiecie linux 6.12.101-1. Nie należy porównywać wyłącznie numerów głównych: dystrybucje przenoszą poprawki także do starszych gałęzi.
Co to oznacza dla administratora?
Plan aktualizacji powinien obejmować hypervisor, a po wdrożeniu trzeba potwierdzić działanie poprawionego jądra. Warto też weryfikować, czy udostępnienie wirtualizacji zagnieżdżonej jest potrzebne. Zmiany konfiguracji wymagają uwzględnienia usług klientów.
Zapscape dotyczy izolacji maszyn wirtualnych. SCTPhantom opisuje inną granicę ochrony: uprawnienia procesów i izolację kontenerów.