Webmin CVE-2026-49243: XSS Reflected Berujung Eksekusi Perintah sebagai Root

Satu klik dari admin Webmin yang sedang login bisa berujung perintah shell jalan sebagai root di server. Riset beaksec yang dirilis 26 September 2026 menunjukkan rantai tiga langkah: parameter yang direfleksikan ke /webmin/index.cgi lolos dari XSS filter, halaman tujuannya dibebaskan dari pemeriksaan anti-CSRF, dan skrip di dalam sesi itu memanggil endpoint yang menjalankan perintah. Versi terdampak adalah Webmin 2.630, 2.640, dan 2.641, tambalannya rilis di 2.650, dan skor resminya naik menjadi 9.6 Critical dengan CVE-2026-49243 yang dicatat sebagai GHSA-hv4w-p8jq-2rp5.

TL;DR

• Rantainya butuh admin yang sedang punya sesi terbuka lalu mengklik satu tautan, tanpa perlu akun penyerang dan tanpa konfigurasi khusus di target.
• Akar XSS-nya adalah asimetri escaping: parameter title lewat html_escape, sementara parameter message lewat filter_javascript, sehingga filter dan browser tidak sepakat soal awal sebuah atribut HTML.
• Langkah kedua dimungkinkan oleh pembebasan pemeriksaan referer di halaman indeks modul Webmin Configuration, jadi klik lintas situs tetap terbawa cookie sesi.
• Langkah ketiga adalah endpoint eksekusi perintah yang memang dirancang berbahaya: miniserv.pl berjalan sebagai root, dan instalasi baru hanya punya satu pemakai, yaitu root:x:0.
• Penilaian risikonya sempat salah dua kali: GHSA terbit 21 Juli 2026 tanpa vektor CVSS, entri CVE keluar 29 September 2026 dengan skor 5.1 Medium, lalu direvisi menjadi 9.6 Critical pada 13 Oktober 2026.

Bagaimana satu tautan berubah jadi shell root?

Langkah pertamanya adalah membandingkan cara filter dan browser membaca markup. Parameter yang masuk lewat query string dipantulkan ke halaman, dan bedanya hanya pada fungsi pelindung yang dipakai: title di-escape sebagai HTML, sedangkan message dilewatkan ke filter_javascript karena isinya memang teks kaya yang harus bisa membawa tautan ke halaman pendaftaran dua faktor. Celahnya muncul dari ketidaksepakatan tentang di mana sebuah atribut HTML dimulai. Filter membuang pola yang dikenalnya, tetapi browser tetap melihat sisinya sebagai atribut yang bisa diisi, sehingga payload bisa bertahan dan tereksekusi di dalam halaman yang sudah terautentikasi.

Langkah kedua adalah soal siapa yang dipercaya halaman itu. Webmin punya pemeriksaan anti-CSRF berbasis referer, tetapi ada jalan pintas yang membebaskan sebagian halaman dari pemeriksaan tersebut. Halaman indeks modul Webmin Configuration di /webmin/index.cgi cocok dengan pola jalan pintas itu, dengan atau tanpa index.cgi di ujungnya, dan modul tersebut tidak mendeklarasikan penanda unsafe_index_cgi yang akan mematikan jalan pintas. Akibatnya klik yang datang dari situs lain tetap menempelkan cookie sesi dan halaman menerimanya sebagai permintaan sah.

Langkah ketiga hanya konsekuensi dari dua langkah di atas. JavaScript yang sudah berjalan di dalam sesi admin bisa memanggil endpoint yang memang menjalankan perintah shell, dan karena miniserv.pl berjalan sebagai root, perintah itu ikut sebagai root. Yang perlu digarisbawahi: tidak ada bug di endpoint tersebut. Endpoint itu melaksanakan fungsi resminya, yaitu mengelola server, dan sisi keamanan Webmin mengharapkan endpoint seperti ini hanya bisa dijangkau dari halaman yang sah.

Kenapa dampaknya langsung sebesar itu?

Karena desain instalasi bawaan Webmin menaruh otoritas tertinggi di satu sesi. Di sistem ada satu pemakai, dan skrip post-install paket menulis satu entri root:x:0 ke berkas pemakai Webmin lalu mendelegasikan autentikasi ke PAM, sehingga kata sandi root sistem yang dipakai. Skrip yang sama juga menambahkan sudo=1, yang membuka jalur masuk bagi kredensial siapa pun di grup sudo. Sesi yang sudah terbentuk karenanya terselesaikan sebagai sesi root, dan riset itu memperlihatkan hasilnya persis seperti di shell: uid=0(root) gid=0(root) groups=0(root). Sejak titik itu, apa pun yang bisa dilakukan root di host terjangkau dari satu klik yang sama.

Yang membuat kasus ini layak dipelajari bukan kecanggihan payload-nya, melainkan betapa banyak lapisan pelindung yang harus gagal lebih dulu supaya satu klik bisa sampai ke root: escaping yang tidak simetris, pengecualian CSRF yang melebar, dan asumsi bahwa endpoint berbahaya hanya akan dipanggil dari halaman internal. Tidak satu pun dari ketiganya terdengar mengerikan sendirian, dan itulah cara kombinasi ini biasa lahir.

Ini juga alasan kategori kerentanannya tidak berhenti di XSS. XSS biasa memaksa penyerang mencuri cookie atau memalsukan aksi. Di Webmin, XSS adalah pintu ke antarmuka administrasinya server, sehingga rantai yang sama menghasilkan eksekusi kode, dan vektor dampaknya lintas batas ke komponen lain. Karena itu pula vektor CVSS-nya memakai Scope Changed, bukan Unchanged.

Seberapa serius skor 9.6 Critical itu?

Vektornya CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, dan tiap huruf menjelaskan satu syarat praktis. Penjelasan lengkap skoringnya ada di spesifikasi FIRST, dan terjemahan kasusnya begitu:

Komponen	Nilai	Implikasi di lapangan
Attack Vector	Network	Serangan datang dari jauh lewat tautan, bukan dari akses lokal.
Attack Complexity	Low	Tidak perlu kondisi langka, race, atau konfigurasi eksperimental.
Privileges Required	None	Penyerang tidak perlu akun Webmin sendiri.
User Interaction	Required	Butuh admin yang sedang login mengklik tautan, satu-satunya syarat yang bisa dilatih.
Scope	Changed	Dampaknya keluar dari komponen yang rapuh ke seluruh host.
Confidentiality, Integrity, Availability	High ketiganya	Akar penuh: baca, ubah, dan matikan layanan bisa dilakukan sekaligus.

Catatan yang layak diambil tim keamanan: skor itu sendiri sempat salah. Advisory GitHub Security Advisory terbit pada 21 Juli 2026 dengan rating Moderate dan tanpa vektor CVSS, lalu entri CVE menyusul pada 29 September 2026 dengan skor 5.1 Medium. Baru pada 8 Oktober 2026 advisory direvisi menjadi Critical dan versi tambalan dikoreksi ke 2.650, dan rekaman CVE ikut diperbarui ke 9.6 Critical pada 13 Oktober 2026. Artinya, tim yang hanya mengandalkan notifikasi skor awal akan menurunkan prioritas tiket ini selama hampir tiga bulan.

Sejak kapan celah ini sebenarnya ada?

Dari laporan forum, bukan dari audit keamanan. Pada 27 Februari 2026 seorang pengguna melapor bahwa setelah mengubah sebuah pengaturan, halaman tidak menampilkan apa pun: tanpa konfirmasi dan tanpa petunjuk langkah berikutnya. Maintainer menanganinya keesokan hari, dan commit d7434c6 pada 28 Februari menutup keluhan itu dengan dua perubahan, yaitu menulis ulang show_restart_page di webmin/webmin-lib.pl agar mengalihkan lewat parameter title dan message, lalu menambahkan pencetakan kotak alert di halaman indeks modul Webmin Configuration. Justru di situlah pasangan escaping yang tidak simetris lahir, dan parameter message, yang dibawa dari redirect itulah yang kemudian dipantulkan apa adanya. Jadi celah keamanan ini adalah efek samping dari perbaikan usability, dan itu pola yang sering terlewat oleh review biasa.

Timeline tambalannya tergolong cepat setelah celah dilaporkan. Peneliti menghubungi tim keamanan Webmin pada 17 Mei 2026 dan tambalan sudah di-commit pada hari yang sama, patch dikonfirmasi pada 23 Mei 2026, dan rilis 2.650 keluar pada 25 Juni 2026. Writeup publik menyusul pada 26 September 2026, dengan pembaruan terakhir 13 Oktober 2026 ketika skor CVE final terbit.

Apa yang harus dilakukan admin Webmin hari ini?

Perbarui ke Webmin 2.650 atau lebih baru, karena itu satu-satunya yang menutup rantainya. Setelah itu, turunkan kemungkinan langkah kedua dan ketiga berhasil: jangan membuka panel Webmin langsung ke publik, pakai pembatas jaringan atau VPN di depan port admin, dan pisahkan akun administrasi dari akun kerja harian sehingga tidak ada sesi root yang menggantung di browser yang dipakai menjelajah. Kalau panel harus diakses dari jauh, lebih baik lewat jump host atau tunnel terautentikasi daripada lewat link yang bisa diklik dari mana saja, karena rantai ini bertumpu pada klik lintas situs yang tetap terbawa cookie.

Untuk developer web, dua pelajaran bisa diambil tanpa menunggu CVE berikutnya. Pertama, escaping harus mengikuti konteks output, bukan maksud penulisnya: satu parameter yang di-escape sebagai HTML dan satu yang tidak, di halaman yang sama, sudah cukup menjadi perbedaan antara bug tampilan dan kerentanan. Kedua, pembebasan pemeriksaan CSRF yang berbasis pola URL perlu diaudit ulang setiap kali modul baru ditambahkan, karena halaman yang tidak sengaja cocok dengan pola itu tetap bisa menerima klik lintas situs sebagai aksi sah.

Bagaimana cara tahu apakah sudah terlanjur kena?

Pertanyaannya tidak bisa dijawab dari satu baris log, karena rantai ini memakai endpoint resmi aplikasi, bukan celah yang meninggalkan jejak memori. Yang realistis diperiksa adalah akibatnya. Bandingkan daftar proses dengan kebiasaan server: anak proses baru dari layanan Webmin yang berjalan sebagai root, cron yang tidak pernah dibuat siapa pun, atau perubahan di berkas sistem yang bukan bagian dari prosedur rutin adalah sinyal yang layak ditindaklanjuti. Cek juga daftar pemakai dan grup sudo di sisi Webmin, karena instalasi bawaannya hanya mengandalkan satu entri admin, sehingga tambahan di sana gampang mencurigakan.

Untuk kasus yang lebih serius, perlakukan host sebagai kemungkinan terkompromi alih-alih mencoba memastikan dari log saja: ambil snapshot, pisahkan jaringan bila memungkinkan, dan evaluasi ulang kredensial yang bisa dijangkau root di mesin itu, termasuk kunci SSH dan token layanan yang tersimpan di direktori kerja. Rantai seperti ini sering berhenti di satu perintah, tetapi pihak yang menaruh endpoint eksekusi perintah sebagai root di panel web tidak pernah bisa berasumsi demikian.

FAQ

Apakah server saya terdampak kalau tidak pernah login ke Webmin?

Rantainya menuntut sesi admin yang sedang terbuka lalu diklik, jadi tanpa sesi itu langkah kedua dan ketiga tidak berjalan. Tetap perbarui, karena versi lama menyimpan endpoint eksekusi perintah yang berjalan sebagai root dan bisa dipanggil dari cara lain.

Versi Webmin mana yang aman?

2.650 ke atas. Versi 2.630, 2.640, dan 2.641 tercatat sebagai terdampak, dan koreksi nomor versi tambalan ini sendiri baru dipublikasikan pada 8 Oktober 2026, sebelumnya advisory menyebut versi yang salah.

Kenapa skor CVE sempat 5,1 lalu jadi 9,6?

Karena penilaian awal tidak memperhitungkan Scope Changed dan jalur akarnya. Advisory GitHub keluar pada 21 Juli 2026 tanpa vektor CVSS, entri CVE terbit 29 September 2026 dengan skor 5.1 Medium, lalu diperbarui ke CVSS 3.1 sebesar 9.6 Critical pada 13 Oktober 2026.

Apakah butuh kredensial untuk mengeksploitasi?

Tidak untuk penyerangnya, karena Privileges Required bernilai None. Yang dibutuhkan adalah kredensial milik orang lain yang sedang aktif: sesi admin di browser, dan itu sebabnya satu klik cukup.