Celah OpenSSH sshole di Alpine Linux dan Cara Menutupnya

Celah OpenSSH yang dijuluki sshole (CVE-2026-123158) memungkinkan penyerang masuk lewat SSH ke akun yang seharusnya tidak dapat dibuka dengan kata sandi, cukup dengan mengirim kata sandi yang sangat panjang. Celah ini menyasar sistem Linux berbasis musl tanpa PAM, terutama Alpine Linux. Perbaikannya tersedia di OpenSSH 10.6p2 dan paket Alpine sejak 5 November 2026.

Cara kerja celah sshole

OpenSSH adalah perangkat lunak yang menjalankan layanan SSH, pintu masuk jarak jauh yang dipakai hampir semua server Linux. Komponen servernya bernama sshd. Di sebagian besar distribusi Linux, sshd memeriksa kata sandi lewat PAM, modul autentikasi bawaan sistem. Alpine Linux berbeda: paket openssh-server bawaannya dibangun tanpa PAM, sehingga sshd memeriksa kata sandi sendiri dengan fungsi crypt() dari pustaka musl.

Menurut advisori resmi Alpine Linux, fungsi crypt() di musl mengembalikan tanda bintang (*) sebagai tanda galat ketika kata sandi lebih panjang dari 256 byte. Tanda bintang yang sama juga dipakai di berkas sistem untuk menandai akun yang tidak memiliki kata sandi, misalnya akun yang hanya boleh masuk dengan kunci SSH. Akibatnya, ketika penyerang mengirim kata sandi sepanjang 257 sampai 1.024 byte, hasil galat itu dianggap cocok dan login diterima.

Akun yang tidak punya kata sandi justru menjadi akun yang paling mudah dibuka. Advisori Alpine menyebut beberapa contoh: akun root pada image dasar sejak sekitar versi 3.16, pengguna yang hanya masuk dengan kunci SSH, pengguna dari layanan direktori, dan pengguna alpine di image cloud resmi.

Peneliti yang menemukannya, Özgün Kültekin dari Wakefield, menelusuri akar masalahnya ke dua perubahan lama. Dalam tulisan risetnya, ia mencatat bahwa perilaku crypt() di musl sudah ada sejak 2012, lalu OpenSSH mengubah cara menangani pengguna tidak valid pada 2016 untuk menutup celah CVE-2016-6210. Ia menguji sekitar 17.600 percobaan login pada berbagai kombinasi glibc, musl, dengan dan tanpa PAM. Hanya kombinasi musl tanpa PAM yang menerima login yang seharusnya ditolak.

Pengelola OpenSSH menyatakan dalam catatan rilis 10.6p2: “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.” Karena itu, perbaikan dipasang di sshd agar sistem terlindungi tanpa menunggu perubahan di pustaka musl.

Status eksploitasi dan tingkat bahaya

Catatan CVE yang diterbitkan MITRE pada 5 November 2026 memberi skor CVSS 3.1 sebesar 8,1 atau tinggi, dengan kompleksitas serangan tinggi dan tanpa perlu akun. Di catatan yang sama, CISA menilai status eksploitasinya pada tingkat proof of concept, artinya cara serangannya sudah terbukti dan terdokumentasi. Hingga 7 November 2026, celah ini belum masuk katalog Known Exploited Vulnerabilities (KEV) milik CISA.

Laporan tentang serangan nyata masih berbeda. Saat Orca Security menerbitkan risetnya pada 5 November, belum ada laporan eksploitasi di luar lab. Sehari kemudian, The Hacker News melaporkan bahwa perusahaan intelijen ancaman Previdian melihat percobaan eksploitasi pertama kurang dari sembilan jam setelah CVE diterbitkan. Previdian mencatat delapan percobaan dan memastikan penyerang memperoleh akses root di honeypot, yaitu server umpan yang menjalankan Alpine Linux dan OpenSSH.

Perbaikan juga datang cepat. Menurut Cycode, OpenSSH dan Alpine merilis perbaikan pada hari yang sama, 5 November 2026. Cycode juga mencatat bahwa pengelola OpenSSH kini tidak lagi memakai masa embargo panjang, karena alat AI dapat menemukan ulang celah yang sudah dilaporkan dalam hitungan jam. Bagi admin, artinya jarak antara pengumuman celah dan serangan pertama dapat sangat pendek.

Sistem yang terdampak dan yang aman

Menurut advisori Alpine, sebuah server terdampak bila semua syarat berikut terpenuhi:

• menjalankan paket openssh-server (tanpa PAM), atau openssh-server-pam dengan setelan UsePAM no;
• PasswordAuthentication bernilai yes, yang merupakan nilai bawaan OpenSSH;
• ada akun dengan tanda * di kolom kata sandinya;
• ada minimal satu akun lokal dengan kata sandi berformat hash $5$ atau $6$.

Syarat terakhir sering terpenuhi tanpa disadari, misalnya ketika admin membuat satu akun dengan kata sandi untuk keperluan darurat. Image cloud resmi Alpine (qcow2, VHD, dan AMI) versi 3.18.11 sampai 3.24.3 membawa pengguna alpine bertanda bintang yang dapat memakai doas, yaitu perintah setara sudo, tanpa kata sandi. Advisori Alpine menyebut image ini aman saat pertama kali menyala, tetapi menjadi rentan begitu ada satu hash $6$ di mesin tersebut.

Sistem yang tidak terdampak menurut advisori Alpine dan riset Orca Security: distribusi berbasis glibc seperti Debian, Ubuntu, dan Fedora; sshd yang memakai PAM; server SSH Dropbear; sistem non-Linux; serta container yang tidak menjalankan sshd. Orca menyebut build OpenWrt, Buildroot, dan Yocto serta image container yang menjalankan sshd mungkin ikut terdampak. Ketiganya juga memakai musl, sehingga perangkat jaringan dan perangkat IoT yang membuka SSH perlu ikut diperiksa.

Versi perbaikan OpenSSH dan Alpine

OpenSSH memperbaiki celah ini di versi 10.6p2. Alpine memasang perbaikan ke semua cabang dari 3.16 sampai edge, termasuk cabang yang sudah tidak didukung. Rilis titik Alpine yang sudah membawa perbaikan adalah 3.21.10, 3.22.8, 3.23.8, dan 3.24.4.

Untuk cabang lama, versi paket perbaikannya adalah 9.7_p1-r6 (3.20), 9.6_p1-r3 (3.19), 9.3_p2-r4 (3.18), 9.1_p1-r7 (3.17), dan 9.0_p1-r6 (3.16). Cycode mencatat bahwa rilis Alpine sebelum 3.16 tidak menerima paket perbaikan, sehingga satu-satunya jalan adalah mematikan login kata sandi.

Pengguna image Docker juga perlu memeriksa image yang menjalankan sshd. Cycode mencatat beberapa image populer seperti Gitea, Gogs, agen SSH Jenkins, dan linuxserver openssh-server sudah mematikan login kata sandi secara bawaan, kecuali bila setelannya diubah. Image buatan sendiri yang berbasis Alpine dan memasang openssh-server perlu dibangun ulang.

Apa artinya bagi tim TI dan pengelola server?

Alpine populer karena ringan, sehingga sering dipakai untuk VPS kecil, server di kampus atau dinas, mesin penghubung (bastion), hingga image container. Server seperti ini sering dibuat sekali lalu jarang disentuh. Langkah berikut dapat dikerjakan hari ini.

Periksa setelan sshd di setiap server

Jalankan sshd -T | grep -i -E 'passwordauthentication|usepam' sebagai root. Server tidak terdampak bila login kata sandi bernilai no atau PAM aktif. Catat juga server berbasis musl lain yang membuka SSH, seperti router OpenWrt atau perangkat IoT buatan sendiri.

Perbarui paket dan mulai ulang sshd

Di Alpine, jalankan pembaruan penuh dengan apk upgrade, lalu mulai ulang layanan dengan rc-service sshd restart. Advisori Alpine menekankan bahwa memperbarui paket saja tidak mengganti sshd yang sedang berjalan. Untuk container, bangun ulang image dan jalankan ulang container dari image baru.

Matikan login kata sandi bila belum dapat memperbarui

Setel PasswordAuthentication no di berkas konfigurasi sshd, misalnya lewat berkas tambahan di /etc/ssh/sshd_config.d/, lalu mulai ulang sshd. Pastikan login dengan kunci SSH berfungsi dan biarkan sesi yang sedang terbuka tetap aktif sebelum perubahan diterapkan, agar akses tidak terkunci. Langkah ini sekaligus praktik baik untuk server yang terhubung ke internet.

Periksa tanda-tanda pembobolan

Cari baris Accepted password for di /var/log/messages untuk akun yang seharusnya tidak punya kata sandi, seperti alpine, root, atau pengguna yang hanya memakai kunci. Periksa juga pemakaian doas, pengguna yang baru dibuat, serta isi berkas authorized_keys. Advisori Alpine meminta mesin diperlakukan sebagai sudah dibobol bila login mencurigakan tidak dapat dipastikan aman.

Tim yang mengelola banyak server dapat menjadikan kasus ini alasan untuk menyusun daftar aset dan jadwal pembaruan yang rutin. Kami membahas pola serupa pada celah Node-RED yang dieksploitasi, ketika layanan yang terbuka ke internet menjadi sasaran pertama. Bila diperlukan, tim layanan keamanan siber Merakit dapat membantu memetakan server yang membuka SSH dan menyusun prosedur penanganan celah.

Pertanyaan yang sering muncul

Apakah server Ubuntu atau Debian saya terdampak?

Tidak, menurut advisori Alpine dan riset Orca. Distribusi berbasis glibc seperti Ubuntu, Debian, dan Fedora memakai pustaka yang berbeda, dan sshd di sana umumnya memeriksa kata sandi lewat PAM. Tetap pasang pembaruan OpenSSH ketika distribusi Anda merilisnya.

Apakah container Alpine biasa ikut terdampak?

Hanya bila container itu menjalankan sshd dengan login kata sandi aktif. Advisori Alpine menyebut container yang tidak menjalankan sshd tidak terdampak. Kebanyakan aplikasi web di container tidak membuka SSH, tetapi image yang dipakai sebagai mesin akses jarak jauh perlu diperiksa.

Apakah cukup memasang paket openssh terbaru?

Belum cukup. Setelah paket diperbarui, sshd perlu dimulai ulang agar versi baru berjalan. Server yang sempat terbuka juga perlu diperiksa lognya, karena percobaan serangan dilaporkan muncul dalam hitungan jam setelah celah diumumkan.

Penutup

Celah sshole hanya terbuka pada kombinasi tertentu, tetapi kombinasi itu adalah setelan bawaan Alpine Linux. Memperbarui OpenSSH, memulai ulang sshd, dan mematikan login kata sandi di server yang terhubung ke internet sudah menutup celah ini. Untuk infrastruktur yang dijalankan di cloud, tim komputasi awan Merakit siap membantu menata image server dan proses pembaruannya.

Sumber

• OpenSSH, catatan rilis 10.6p2 (5 November 2026)
• Alpine Linux, advisori openssh-server password authentication bypass (5 November 2026)
• Catatan CVE-2026-123158, CVE Program (5 November 2026)
• Orca Security, *sshole: OpenSSH Authentication Bypass Gives Attackers Root on Alpine Linux (5 November 2026)
• Cycode melalui Security Boulevard, sshole (CVE-2026-123158) (5 November 2026)
• The Hacker News, Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure (6 November 2026)
• Özgün Kültekin, tulisan riset *sshole (November 2026)