Sebuah celah di OpenSSH bernama SSHole (CVE-2026-123158) memungkinkan penyerang masuk ke server lewat SSH tanpa mengetahui password. Cukup dengan mengirim password yang sangat panjang, lebih dari 256 karakter. Celah ini hanya berlaku pada sistem Linux berbasis pustaka musl libc yang tidak memakai PAM, dan contoh paling umumnya adalah Alpine Linux.
Celah ini bukan lagi sekadar teori. Badan keamanan siber Amerika Serikat, CISA, memasukkan CVE-2026-123158 ke katalog Known Exploited Vulnerabilities (KEV) pada 9 November 2026. Perusahaan intelijen ancaman GreyNoise juga mencatat serangan berhasil sejak 7 November, termasuk dari alamat IP jaringan Indonesia. Perbaikannya sudah tersedia di OpenSSH 10.6p2 dan paket Alpine terbaru.
Ringkasan
| Aspek | Detail |
|---|---|
| Nama / CVE | SSHole, CVE-2026-123158 |
| Jenis | Bypass autentikasi password di sshd (CWE-394, nilai kembalian tak terduga) |
| Skor CVSS 3.1 | 8.1 (High) |
| Terdampak | sshd di OpenSSH sebelum 10.6p2, di Linux dengan musl libc dan tanpa PAM (contoh: Alpine Linux) |
| Perbaikan | OpenSSH 10.6p2 (5 November 2026) dan paket Alpine untuk cabang 3.16 hingga edge |
| Status eksploitasi | Aktif dieksploitasi; masuk CISA KEV 9 November 2026, tenggat lembaga federal AS 12 November 2026 |
| Penemu | Özgün Kültekin dari Wakefield |
Bagaimana Celah Ini Bekerja?
Menurut advisory resmi Alpine Linux dan tulisan penemunya, masalahnya muncul dari pertemuan tiga keputusan lama yang masing-masing masuk akal:
- Tanda bintang (
*) untuk akun tanpa password. Di/etc/shadow, akun yang tidak boleh login dengan password (misalnya root di Alpine sejak sekitar versi 3.16, atau user yang hanya memakai SSH key) diisi*sebagai pengganti hash password. - Perilaku
crypt()di musl. Sejak 2012, fungsicrypt()di musl menolak password SHA-256/SHA-512 yang panjangnya lebih dari 256 byte. Saat gagal, fungsi ini mengembalikan string*sebagai tanda error. - “Pinjam salt” di sshd. Sejak perbaikan CVE-2016-6210 (celah yang bisa menebak username lewat perbedaan waktu respons), sshd tetap meng-hash password untuk akun yang tidak punya hash valid, dengan meminjam salt dari akun lain yang punya hash.
Hasilnya: saat penyerang mengirim password sepanjang 257 sampai 1024 byte untuk akun yang isinya *, sshd meminjam salt dari akun lain, crypt() musl gagal dan mengembalikan *, lalu sshd membandingkannya dengan isi /etc/shadow yang juga *. Keduanya cocok, dan login dianggap berhasil.
Tim Alpine menulis, “An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.” Artinya, cukup satu koneksi, selalu berhasil, dan tidak perlu mencoba berulang kali.
Dalam catatan rilis 10.6p2, tim OpenSSH menyebut akar masalahnya berada di luar sshd, tetapi bisa dieksploitasi lewat sshd sehingga dicegah di sana.
Siapa yang Terdampak?
Menurut advisory Alpine, sebuah sistem rentan jika semua syarat berikut terpenuhi:
- Menjalankan paket
openssh-serverAlpine (dibangun tanpa PAM), atauopenssh-server-pamdenganUsePAM no. PasswordAuthenticationbernilaiyes. Ini adalah bawaan OpenSSH jika tidak diubah.- Ada akun dengan isi password
*, misalnya root, user khusus SSH key yang dibuat denganaddusertanpa password, user dari layanan direktori lewat musl-nscd, atau useralpinedi image cloud resmi. - Ada minimal satu akun lokal lain yang punya hash password
$5$atau$6$.
| Rentan | Tidak rentan |
|---|---|
| Alpine 3.16 sampai 3.24 dan edge (sebelum update) | Distro berbasis glibc seperti Debian, Ubuntu, Fedora (menurut penemu) |
| Image cloud resmi Alpine (tiny-cloud) 3.18.11 sampai 3.24.3, begitu ada akun dengan hash password | Sistem dengan PasswordAuthentication no |
| Kemungkinan OpenWrt, Buildroot, Yocto, dan image Docker berbasis musl yang menjalankan sshd (disebut penemu sebagai sistem yang perlu dicek) | openssh-server-pam dengan UsePAM yes |
| Container Docker yang tidak menjalankan sshd di dalamnya | |
Image cloud yang dikonfigurasi lewat cloud-init (otomatis menulis PasswordAuthentication no) |
Kenapa root tetap berbahaya walau ada PermitRootLogin
Pengaturan bawaan OpenSSH PermitRootLogin prohibit-password mencegah root login dengan password. Namun Alpine mengingatkan, perlindungan ini tidak berarti apa-apa jika ada akun lain yang bisa login dan naik menjadi root, misalnya lewat doas. Pada image cloud resmi Alpine, user alpine punya isi password * dan bisa memakai doas tanpa password. Begitu ada satu akun dengan hash password di mesin itu (misalnya admin mengatur password konsol), penyerang bisa masuk sebagai alpine lalu menjadi root.
Bagaimana dengan pengguna Docker?
Advisory Alpine tegas menyebut container Docker yang tidak menjalankan sshd tidak terdampak. Sebagian besar image berbasis alpine memang tidak menjalankan SSH server. Risiko muncul pada image atau container yang sengaja menjalankan sshd, misalnya image “SSH server”, bastion, atau container untuk transfer file via SFTP. Di GitHub, pengelola proyek seperti Coolify (platform self-hosting yang mendukung Alpine) juga sudah menerima usulan untuk mematikan login password secara eksplisit di skrip instalasinya.
Kronologi (WIB)
Kronologi berikut disusun dari halaman pemantauan GreyNoise, catatan rilis OpenSSH, NVD, dan katalog CISA KEV.
| Waktu (WIB) | Kejadian |
|---|---|
| Kamis 5 Nov 2026, 16.00 | Perbaikan dipublikasikan di repositori OpenSSH; satu menit kemudian OpenSSH 10.6p2 diumumkan. Alpine merilis advisory dan paket perbaikan di hari yang sama. |
| 5 Nov, 19.19 | Tulisan teknis peneliti, yang menjelaskan cara memicu celah, dipublikasikan. |
| 5 Nov, 20.16 | Kode exploit publik pertama muncul di GitHub, 2,5 jam sebelum nomor CVE dipesan. |
| 5 Nov, 22.46 dan 23.17 | CVE-2026-123158 terbit di CVE.org, lalu di NVD dengan skor CVSS 8.1. |
| Sabtu 7 Nov, 07.46 | GreyNoise mencatat eksploitasi berhasil pertama terhadap sensor miliknya. |
| Senin 9 Nov | CISA memasukkan CVE-2026-123158 ke katalog KEV, dengan tenggat perbaikan untuk lembaga federal AS pada 12 November. |
Serangan Nyata di Lapangan
Temuan Previdian
Kepada Help Net Security, pendiri perusahaan intelijen ancaman Previdian, Ryan Dewhurst, mengatakan percobaan serangan pertama yang mereka lihat datang kurang dari sembilan jam setelah CVE dipublikasikan. Previdian juga mengonfirmasi penyerang berhasil mendapat akses root di honeypot yang menjalankan Alpine Linux dan OpenSSH asli. Penyerang memakai password berukuran sangat besar, lalu menjalankan perintah pengintaian seperti id, uname, dan hostname.
Data GreyNoise
GreyNoise memasang server rentan sebagai umpan dan memantau aktivitasnya. Per pembaruan 14 November 2026, halaman pemantauan mereka mencatat:
- Aktivitas pasca-eksploitasi terkonfirmasi dari 10 alamat IP penyerang.
- GreyNoise merinci tujuh penyerang, termasuk satu klaster yang diberi nama GT10. Alamat IP penyerang lainnya berasal dari jaringan di Mesir, Spanyol, Singapura, Tiongkok, dan Indonesia.
- Dua alamat IP dari jaringan penyedia di Indonesia masing-masing tercatat melakukan dua intrusi pada 10 dan 11 November. GreyNoise mengingatkan bahwa sebagian alamat penyerang bisa jadi merupakan infrastruktur sah yang sudah dibobol, jadi asal IP tidak otomatis menunjukkan pelaku.
- Klaster GT10 menanam runtime Python dan sebuah implant bernama TAC Agent, yaitu program pengendali jarak jauh yang komentar dan pesan error-nya berbahasa Tionghoa. Menurut GreyNoise, pada korban yang diamati, pendaftaran agen ke server C2 tidak berhasil.
- Seorang penyerang lain, setelah masuk, memeriksa apakah sistem berjalan di dalam container, mengakses layanan metadata AWS, Azure, dan Alibaba Cloud, lalu mencoba membaca SSH key root dan hash password di
/etc/shadowlewatdoas.
Previdian juga mengingatkan bahwa kode exploit yang beredar di GitHub belum terverifikasi dan bisa saja berisi malware. Jangan menjalankannya sembarangan.
Cara Mengecek dan Memperbaiki
1. Update dan restart sshd
Ini langkah utama dari advisory Alpine:
apk upgrade -U -a rc-service sshd restart
Penting: memperbarui paket tidak otomatis me-restart sshd yang sedang berjalan. Selama sshd lama belum di-restart, celah masih terbuka.
Versi paket yang sudah diperbaiki menurut Alpine:
| Cabang Alpine | Versi openssh yang aman |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Rilis titik Alpine 3.21.10, 3.22.8, 3.23.8, dan 3.24.4 sudah membawa paket yang diperbaiki. Alpine juga merilis paket perbaikan untuk cabang lama hingga 3.16, termasuk 3.21 yang dukungannya berakhir pada 1 November 2026.
2. Jika belum bisa update: matikan login password
Pengembang OpenSSH Damien Miller, seperti dikutip Help Net Security, meminta pengguna Linux berbasis musl tanpa PAM untuk segera mengatur PasswordAuthentication no atau mematikan SSH di sistem tersebut. Pastikan login dengan SSH key sudah berfungsi, dan jangan tutup sesi yang sedang aktif sebelum login baru berhasil diuji. Perintah dari advisory Alpine:
mkdir -p /etc/ssh/sshd_config.d echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf sed -i.bak -e '1i PasswordAuthentication no' \ -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \ /etc/ssh/sshd_config sshd -t && rc-service sshd restart sshd -T | grep -i passwordauthentication
Perintah terakhir harus menampilkan passwordauthentication no. Folder sshd_config.d baru dibaca oleh konfigurasi bawaan Alpine sejak 3.19; untuk versi lebih lama, perintah sed di atas yang mengubah file utama.
3. Cek apakah sistem memenuhi syarat rentan
Dua perintah berikut membaca /etc/shadow (jalankan sebagai root) untuk melihat akun berisi * dan akun yang punya hash $5$/$6$. Jika keduanya sama-sama ada dan login password aktif, sistem rentan sebelum di-update.
awk -F: '$2=="*" {print "tanpa password:", $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "punya hash:", $1}' /etc/shadow
4. Cari jejak pembobolan
Alpine menyarankan mencari baris Accepted password for di /var/log/messages untuk akun yang seharusnya tidak punya password, misalnya alpine, root, atau user khusus SSH key:
grep "Accepted password for" /var/log/messages
Periksa juga penggunaan doas, user yang baru dibuat, file yang baru berubah, dan isi authorized_keys. Jika login penyerang tidak bisa dipastikan tidak terjadi, Alpine menyarankan memperlakukan mesin itu sebagai sudah dibobol.
5. Untuk pengguna Docker
- Cari container yang menjalankan sshd. Contoh:
docker ps --format '{{.Names}} {{.Image}}', lalu periksa image yang berbasis Alpine dan memang menyediakan SSH. - Bangun ulang (rebuild) image tersebut dari base image Alpine terbaru, atau tambahkan
apk upgradedi Dockerfile, lalu jalankan ulang container-nya. - Pastikan port SSH container tidak terbuka langsung ke internet jika tidak benar-benar perlu.
Peran AI: Celah Ditemukan dan Dieksploitasi Lebih Cepat
Penemu celah, Özgün Kültekin, mengaku memakai banyak agen AI (“agent swarms”) saat mencoba sekitar 17.600 variasi login tidak lazim ke berbagai build sshd, menurut Help Net Security. Dalam catatan rilis 10.6p2, tim OpenSSH juga menulis bahwa mereka menerima banyak laporan bug yang ditemukan dengan bantuan AI. Mereka melihat beberapa bug temuan AI kemudian ditemukan juga secara terpisah oleh peneliti lain, sehingga penyerang yang tidak melaporkan bug kemungkinan bisa menemukannya juga. Karena itu, OpenSSH untuk sementara akan merilis versi baru lebih sering.
Di sisi penyerang, Dewhurst dari Previdian menilai penyerang makin cepat dengan bantuan AI, ditambah celah ini sangat mudah dieksploitasi. Data GreyNoise menunjukkan jarak dari kode exploit publik ke eksploitasi berhasil pertama hanya sekitar satu setengah hari.
Analisis redaksi: pola ini mirip dengan zero-day Chrome yang kami bahas sebelumnya di Zero-day Chrome CVE-2026-125350: jarak antara perbaikan dirilis dan serangan nyata makin pendek. Bagi tim IT, jadwal patch bulanan tidak lagi cukup untuk layanan yang terbuka ke internet seperti SSH. Kebiasaan sederhana seperti mematikan login password dan hanya memakai SSH key akan menutup banyak risiko sekaligus, termasuk celah semacam SSHole.
Kesimpulan
SSHole adalah celah yang sangat mudah dieksploitasi pada konfigurasi tertentu: OpenSSH di Linux berbasis musl tanpa PAM, dengan login password aktif. Alpine Linux memenuhi syarat itu secara bawaan, sehingga server, VPS, image cloud, dan container Alpine yang menjalankan sshd perlu segera diperiksa. Serangan nyata sudah terjadi sejak 7 November, termasuk dari jaringan di Indonesia. Langkah yang perlu dilakukan sederhana: update paket openssh, restart sshd, dan matikan login password jika memungkinkan. Sistem berbasis glibc seperti Debian dan Ubuntu, serta container yang tidak menjalankan sshd, tidak terdampak.
Sumber
- Alpine Linux: Security advisory: openssh-server password authentication bypass
- OpenSSH: Release Notes (OpenSSH 10.6p2)
- NVD: CVE-2026-123158
- CISA: Known Exploited Vulnerabilities Catalog, CVE-2026-123158
- GreyNoise: SSHole (CVE-2026-123158) Activity 2026
- Özgün Kültekin: *sshole (tulisan teknis penemu)
- Help Net Security: OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158)
- GitHub Coolify: Harden Alpine SSH installation against CVE-2026-123158 (SSHole)
[…] ini saja, kita melihat celah OpenSSH SSHole dieksploitasi kurang dari dua hari setelah kode exploit beredar, dan server N-able N-central […]