Celah KVM Berusia 16 Tahun Bikin Mesin Virtual Bisa Bobol Host Intel dan AMD
Baca dalam 60 detik
- Kerentanan use-after-free di shadow MMU KVM memungkinkan tamu VM mengambil alih host, memengaruhi prosesor Intel dan AMD x86.
- Eksploitasi membutuhkan akses root di dalam VM dan nested virtualization; kode perbaikan sudah dirilis pada kernel stabil 4 Juli 2026.
- Peneliti Hyunwoo Kim mengungkap celah ini setelah 16 tahun tidak terdeteksi, menjadikannya ancaman serius bagi penyedia cloud multi-tenant.

Sebuah kerentanan berusia 16 tahun di hypervisor KVM Linux memungkinkan mesin virtual tamu (guest VM) untuk melarikan diri dan mengambil alih kendali penuh atas sistem host, baik pada prosesor Intel maupun AMD x86. Celah yang dijuluki 'Januscape' ini ditemukan oleh peneliti keamanan Hyunwoo Kim dan telah dilaporkan ke Google melalui program kvmCTF, yang menawarkan hadiah hingga US$250.000 untuk eksploitasi guest-to-host yang lengkap.
Kerentanan dengan kode CVE-2026-53359 ini terletak pada kode shadow MMU yang digunakan bersama oleh KVM untuk Intel dan AMD. Akar masalahnya adalah kesalahan logika saat KVM mencari halaman pelacakan (shadow page) untuk digunakan kembali. KVM hanya mencocokkan alamat memori tanpa memeriksa tipe halaman, sehingga dua jenis halaman berbeda yang kebetulan berada di alamat yang sama bisa tertukar. Akibatnya, struktur data internal KVM menjadi kacau, dan dalam skenario terburuk, memori yang sudah dibebaskan dapat ditimpa dengan nilai yang dikendalikan penyerang, membuka jalan untuk eksekusi kode di host.
Menurut Kim, eksploitasi ini adalah yang pertama kali dipublikasikan dan dapat dipicu pada arsitektur Intel dan AMD secara bersamaan. Bukti konsep (PoC) yang dirilis publik hanya menyebabkan host panik (crash), tetapi Kim mengklaim telah mengembangkan eksploitasi terpisah yang memungkinkan eksekusi kode penuh di host. Serangan memerlukan dua kondisi dari sisi tamu: akses root di dalam VM dan fitur nested virtualization yang diaktifkan oleh host. Bahkan pada host yang menggunakan hardware-assisted paging (EPT/NPT), nested virtualization memaksa KVM kembali ke shadow MMU lama yang rentan.
Dampak paling nyata adalah pada lingkungan cloud multi-tenant yang menjalankan x86 KVM dengan nested virtualization diaktifkan. Seorang penyewa jahat dapat memicu panic host, menjatuhkan semua VM lain di mesin fisik yang sama. Kim juga mencatat bahwa pada distribusi seperti RHEL, di mana /dev/kvm dapat ditulis oleh semua pengguna (0666), celah yang sama dapat digunakan untuk eskalasi hak istimewa lokal menjadi root, meskipun jalur guest-to-host dianggap lebih berbahaya.
Bagi pengguna dan operator cloud di Indonesia, temuan ini menjadi pengingat akan pentingnya manajemen patch yang ketat. Banyak penyedia layanan cloud lokal yang mengandalkan infrastruktur KVM untuk menyewakan mesin virtual. Jika nested virtualization diaktifkan secara default atau tanpa pengawasan, risiko kebocoran antar-penyewa menjadi nyata. Langkah mitigasi sementara adalah menonaktifkan nested virtualization melalui parameter kernel (kvm_intel.nested=0 atau kvm_amd.nested=0) sambil menunggu patch dari distributor. Debian telah merilis perbaikan untuk versi pengujian dan tidak stabil, sementara Ubuntu, Red Hat, dan turunannya masih dalam proses.
Peneliti Hyunwoo Kim, yang sebelumnya menemukan kerentanan Dirty Frag dan ITScape, menekankan bahwa Januscape adalah bagian dari tren peningkatan serangan terhadap hypervisor. Dalam dua bulan terakhir, dua celah use-after-free di shadow MMU yang sama telah ditemukan dan diperbaiki. Hal ini menunjukkan bahwa kode lawas KVM masih menyimpan banyak potensi bahaya. Google meluncurkan program kvmCTF pada 2024 justru karena KVM menjadi fondasi Android dan Google Cloud, sehingga insentif bagi peneliti untuk menemukan celah semacam ini semakin besar.
Ke depan, para administrator sistem dan penyedia cloud di Indonesia harus segera mengaudit lingkungan KVM mereka, memastikan patch telah terinstal, dan mempertimbangkan untuk menonaktifkan nested virtualization jika tidak diperlukan. Pertanyaan yang tersisa adalah: seberapa cepat ekosistem cloud Indonesia dapat merespons ancaman yang sudah 16 tahun mengintai ini?



