Wirtualizacja opiera się na jednym cichym założeniu: maszyna wirtualna jednego klienta nie ma jak dosięgnąć hosta ani maszyn jego sąsiadów. Odkryta w lipcu 2026 roku luka nazwana Januscape pokazuje, że to założenie potrafi się załamać. Błąd w hypervisorze KVM — sercu wirtualizacji na Linuksie, na którym stoi ogromna część chmury publicznej i hostingu VPS — pozwala uruchomionej w maszynie wirtualnej osobie wyjść poza jej granice i sięgnąć do systemu gospodarza. Co gorsza, luka siedziała w kodzie jądra Linuksa przez około 16 lat, zanim ktokolwiek ją zauważył.
Na czym polega problem
Januscape (CVE-2026-53359) to podatność typu use-after-free w tzw. shadow MMU — części KVM odpowiedzialnej za odwzorowywanie pamięci maszyny wirtualnej. Żeby uruchomić VM-kę, KVM prowadzi własny, prywatny zestaw tablic stron, które lustrzanie odtwarzają układ pamięci gościa. Kiedy potrzebuje takiej strony śledzącej, szuka istniejącej do ponownego wykorzystania — i tu tkwił błąd. KVM dopasowywał je wyłącznie po adresie w pamięci, ignorując, jakiego typu jest dana strona. Dwie różne strony mogą leżeć pod tym samym adresem, ale pełnić zupełnie inne role, więc KVM potrafił sięgnąć po niewłaściwą.
Efektem jest rozjechanie wewnętrznych rejestrów hypervisora — informacji o tym, która strona pamięci należy do czego. Najczęściej jądro samo wykrywa ten chaos i awaryjnie się wyłącza, żeby nie narobić szkód. Właśnie to demonstruje publiczny kod PoC: goszcząca maszyna potrafi jednym uderzeniem położyć całego hosta, a wraz z nim wszystkie pozostałe VM-ki na tej samej fizycznej maszynie. Rzadszy, znacznie groźniejszy scenariusz następuje, gdy zwolniona strona zostanie wydana do innego użytku, zanim jądro posprząta — wtedy porządkowanie zapisuje wartość w pamięć, która już do niej nie należy. To wystarczający punkt zaczepienia, by dojść do wykonania kodu na hoście.
Dlaczego to ważne dla hostingu i chmury
Autor, Hyunwoo Kim (@v4bel), opisuje Januscape jako pierwszy publicznie znany atak guest-to-host działający zarówno na procesorach Intela, jak i AMD — wcześniejsze tego typu badania ograniczały się do jednej architektury. Do ataku potrzebne są dwie rzeczy: uprawnienia roota wewnątrz maszyny wirtualnej (na wynajętym VPS-ie to norma — to twoja maszyna) oraz włączona zagnieżdżona wirtualizacja (nested virtualization) po stronie hosta. Nawet na serwerach korzystających sprzętowo z EPT/NPT zagnieżdżona wirtualizacja zawraca KVM na starą ścieżkę shadow MMU, czyli dokładnie tam, gdzie mieszka błąd.
Praktyczny wniosek jest brutalnie prosty: w środowisku wielu najemców napastnik wynajmuje jedną instancję i może położyć hosta razem z maszynami wszystkich sąsiadów. Kim twierdzi, że jego niepublikowany, pełny exploit uruchamia kod jako root na gospodarzu — co odsłania pozostałych gości na tej samej maszynie. Na dystrybucjach takich jak RHEL, gdzie /dev/kvm bywa zapisywalny dla wszystkich (0666), ten sam błąd może posłużyć również do lokalnego podniesienia uprawnień do roota.
Co zrobić
Naprawa trafiła do głównej gałęzi jądra 19 czerwca 2026 (commit 81ccda30b4e8), a stabilne wersje z łatką wyszły 4 lipca: między innymi 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 i 5.10.260. Jeśli prowadzisz host KVM z x86, który przyjmuje niezaufanych gości, sprawdź, czy twoje jądro zawiera ten commit. Uwaga — backporty w dystrybucjach potrafią nieść łatkę pod innym numerem wersji, więc zaglądaj do changeloga pakietu, a nie tylko do uname -r. Ważne: pełne załatanie wymaga też drugiej poprawki, CVE-2026-46113 — samo załatanie wcześniejszego błędu nie zatrzymuje Januscape.
Jeśli nie możesz zaktualizować od razu, tymczasowo wyłącz zagnieżdżoną wirtualizację (kvm_intel.nested=0 lub kvm_amd.nested=0) — to usuwa ścieżkę ataku dla niezaufanych gości. Hosty ARM64 nie są podatne na Januscape. Warto też zawęzić uprawnienia do /dev/kvm tam, gdzie nie muszą być tak liberalne.
Podsumowanie
Januscape przypomina, że wirtualizacja to tylko tak silna izolacja, jak kod, który ją utrzymuje — a ten kod może latami skrywać błąd. Dla użytkownika VPS-a czy chmury lekcja jest praktyczna: pytaj dostawcę, czy host ma aktualne jądro, i nie zakładaj, że sąsiad z tego samego serwera nie jest problemem. Dla każdego, kto sam prowadzi hosting, to sygnał, żeby aktualizacja jądra hosta stała na samym szczycie listy priorytetów.
źródło: https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html