softovator.com

SSHole (CVE-2026-123158): Celah OpenSSH di Alpine Linux Bisa Login Tanpa Password, Sudah Dieksploitasi

Redaksi Softovator
Ilustrasi celah SSHole OpenSSH: password sangat panjang membuka gembok SSH di server Alpine Linux

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:

  1. 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.
  2. Perilaku crypt() di musl. Sejak 2012, fungsi crypt() di musl menolak password SHA-256/SHA-512 yang panjangnya lebih dari 256 byte. Saat gagal, fungsi ini mengembalikan string * sebagai tanda error.
  3. “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:

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:

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

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

Exit mobile version