Zapscape (CVE-2026-64561): ucieczka z KVM do hosta

Zapscape (CVE-2026-64561) to groźna luka w KVM/x86, która przy aktywnej wirtualizacji zagnieżdżonej może pozwolić maszynie VM przejąć hosta.

6 sierpnia 2026 • root • PrywatnyInformatyk.pl

Najważniejsze: administrator maszyny gościnnej może wywołać błąd w jądrze hosta, doprowadzić do jego awarii albo wykonać na nim kod z uprawnieniami roota. Debian 13 „Trixie” usuwa podatność w pakiecie linux 6.12.101-1. Aktualizacja musi zostać zainstalowana na hoście KVM, po czym host należy ponownie uruchomić.

Czym jest Zapscape?

Zapscape to nazwa podatności CVE-2026-64561 w module KVM dla architektury x86. KVM jest częścią jądra Linux i odpowiada za sprzętowo wspomaganą wirtualizację. Korzystają z niego między innymi QEMU, libvirt, Proxmox VE oraz liczne publiczne i prywatne platformy chmurowe.

Błąd umożliwia przełamanie jednej z najważniejszych granic bezpieczeństwa w środowisku wirtualnym: izolacji pomiędzy maszyną gościnną a systemem hosta.

Na czym polega podatność?

KVM utrzymuje dodatkowe struktury służące do tłumaczenia adresów pamięci używanych przez maszynę wirtualną na adresy pamięci hosta. Jednym z wykorzystywanych mechanizmów jest tak zwany shadow MMU, czyli zestaw pomocniczych tablic stron zarządzanych przez jądro hosta.

Podczas odzyskiwania pamięci KVM może unieważnić używaną główną tablicę stron. Problem polega na tym, że sprawdzenie, czy tablica nadal jest prawidłowa, następowało zbyt wcześnie. Pomiędzy sprawdzeniem a utworzeniem nowego mapowania mechanizm odzyskiwania pamięci mógł oznaczyć aktywny korzeń tablic jako nieważny.

KVM próbował następnie umieszczać kolejne mapowania w unieważnionej strukturze. Nowe podrzędne strony dziedziczyły jej nieprawidłowy stan, mimo że jednocześnie znajdowały się na liście aktywnych stron MMU. Naruszało to wewnętrzne założenia KVM i prowadziło do błędu typu use-after-free.

Jak możliwa jest ucieczka z maszyny wirtualnej?

Atakujący posiadający uprawnienia roota w maszynie gościnnej może uruchomić w niej kolejną maszynę wirtualną i odpowiednio zmieniać tryby stronicowania pamięci. Powoduje to utworzenie szczególnego układu tablic stron, a następnie wywołanie mechanizmu odzyskiwania stron KVM na hoście.

Po wystąpieniu błędu zwolniona strona może zostać ponownie przydzielona i wypełniona danymi kontrolowanymi przez gościa. Opublikowany łańcuch wykorzystania pozwala przekształcić tę sytuację w wykonanie kodu w jądrze hosta.

W praktyce oznacza to możliwość:

wywołania kernel panic na hoście i zatrzymania wszystkich działających na nim maszyn;
wykonania kodu z uprawnieniami roota na hoście;
uzyskania dostępu do danych innych maszyn wirtualnych;
przejęcia całego węzła wirtualizacyjnego;
naruszenia izolacji klientów w środowisku wielodostępnym.

Publiczny PoC i warunki ataku

Autor podatności opublikował kod demonstracyjny pokazujący pełną ucieczkę z gościa do hosta. Po udanym ataku PoC tworzy na hoście plik należący do użytkownika root, potwierdzając wykonanie operacji poza maszyną wirtualną.

Opublikowany PoC został przygotowany dla procesorów AMD i mechanizmu SVM/NPT. Nie jest to uniwersalny exploit, który bez zmian zadziała na każdym serwerze chmurowym. Wymaga dopasowania do konfiguracji jądra i przeniesienia części operacji do kodu uruchamianego w jądrze gościa. Autor ocenia jednak, że takie przeniesienie nie jest szczególnie trudne.

Znana ścieżka ataku wymaga:

hosta KVM na architekturze x86;
udostępnienia gościowi wirtualizacji zagnieżdżonej;
uprawnień roota wewnątrz maszyny gościnnej;
możliwości uruchomienia przez gościa kolejnego poziomu wirtualizacji.

W przypadku procesorów Intel możliwość wywołania znanej ścieżki jest węższa. Według autora gość musi otrzymać jednocześnie określone możliwości dotyczące 4- i 5-poziomowego przechodzenia po tablicach EPT.

Dlaczego root w maszynie gościnnej nie jest wystarczającym zabezpieczeniem?

W usługach VPS klient zazwyczaj zgodnie z przeznaczeniem otrzymuje pełne uprawnienia administratora własnej maszyny. Nie jest to naruszenie bezpieczeństwa. Hypervisor musi zakładać, że administrator VM może uruchomić dowolne jądro, sterownik i kod niskopoziomowy wewnątrz swojego systemu.

Dlatego wymaganie roota w gościu nie zmniejsza znacząco ryzyka dla dostawcy hostingu. Jeżeli klient może za pomocą dozwolonych operacji przejść z własnej VM do jądra hosta, podatność łamie podstawową granicę izolacji platformy.

Czy problem znajduje się w QEMU?

Nie. Zapscape znajduje się w module KVM działającym w jądrze Linux, a nie w emulacji urządzeń QEMU. Oznacza to, że sama aktualizacja pakietu QEMU nie usuwa podatności. Zagrożone mogą być również platformy używające własnego oprogramowania zarządzającego maszynami, jeżeli pod spodem korzystają z podatnego KVM.

Jak sprawdzić, czy host korzysta z KVM i nested virtualization?

uname -r lsmod | grep '^kvm' cat /sys/module/kvm_amd/parameters/nested 2>/dev/null cat /sys/module/kvm_intel/parameters/nested 2>/dev/null stat -c '%A %U:%G %n' /dev/kvm 2>/dev/null

Wartość Y albo 1 przy parametrze nested zwykle oznacza, że wirtualizacja zagnieżdżona jest włączona. Należy dodatkowo sprawdzić konfigurację poszczególnych maszyn, ponieważ ostateczne ryzyko zależy również od tego, jakie flagi procesora zostały przekazane gościowi.

W środowisku libvirt pomocne może być sprawdzenie konfiguracji CPU maszyny:

virsh dumpxml NAZWA_VM | grep -E 'host-passthrough|vmx|svm'

W Proxmox VE należy również przejrzeć ustawienie CPU maszyny oraz sprawdzić, czy wewnątrz gościa widoczne są flagi vmx lub svm.

Jak zainstalować poprawkę w Debianie 13?

Podatne są jądra zawierające kod obecny od wersji Linux 5.9. Pierwszą poprawioną wersją stabilnej gałęzi 6.12 jest 6.12.101. Debian udostępnił poprawkę w pakiecie źródłowym linux 6.12.101-1.

apt update apt full-upgrade reboot

Po restarcie trzeba sprawdzić, czy host rzeczywiście uruchomił nowe jądro:

uname -r apt-cache policy linux-image-amd64

Aktualizacja jądra wewnątrz maszyn gościnnych nie naprawia podatnego hosta. Poprawiony musi zostać kernel fizycznego węzła KVM.

Jeżeli host korzysta z jądra dostarczanego przez producenta platformy, na przykład pakietu proxmox-kernel-*, należy zainstalować poprawioną wersję z repozytorium tego producenta. Numeru takiego pakietu nie należy bezpośrednio porównywać z numerem pakietu linux w Debianie.

Tymczasowe ograniczenie ryzyka

Do czasu instalacji poprawki i restartu można ograniczyć znany wektor ataku poprzez:

wyłączenie nested virtualization, jeśli nie jest potrzebna;
nieprzekazywanie gościom flag vmx i svm;
wstrzymanie uruchamiania niezaufanych maszyn na podatnym hoście;
ograniczenie dostępu lokalnych użytkowników do /dev/kvm;
przeniesienie szczególnie wrażliwych VM na poprawione węzły.

Zmiana parametru nested zwykle wymaga zatrzymania maszyn i ponownego załadowania modułu KVM albo restartu hosta. Nie należy wykonywać jej bez sprawdzenia zależności działających maszyn.

Podsumowanie

Zapscape jest podatnością o bardzo dużym znaczeniu dla operatorów KVM, Proxmox VE i usług VPS. Publiczny PoC pokazuje, że błąd może zostać wykorzystany nie tylko do awarii hosta, ale również do wykonania kodu z uprawnieniami roota poza maszyną gościnną.

Hosty udostępniające klientom nested virtualization powinny zostać zaktualizowane w pierwszej kolejności. Niezależnie od konfiguracji najbezpieczniejszym rozwiązaniem jest instalacja poprawionego jądra, kontrolowane zatrzymanie lub migracja maszyn oraz ponowne uruchomienie węzła.

Źródła

Potrzebujesz pomocy z aktualizacją hosta KVM lub Proxmox?
W ramach usług PrywatnyInformatyk.pl zajmujemy się administracją, aktualizacjami bezpieczeństwa, monitoringiem oraz zabezpieczaniem serwerów i środowisk wirtualizacyjnych.