Celah OpenSSH sshole (CVE-2026-123158): Login Tanpa Password di Alpine Linux, Cek dan Tambal Sekarang

CVE-2026-123158, dijuluki "sshole", adalah celah bypass autentikasi password di OpenSSH yang membuat server Alpine Linux menerima login ke akun tanpa password yang benar. Skor CVSS 3.1-nya 8.1, perbaikannya ada di OpenSSH 10.6p2 (5 November 2026), dan CISA memasukkannya ke katalog Known Exploited Vulnerabilities pada 9 November 2026.

Celah ini penting karena Alpine adalah basis banyak image Docker dan VM cloud yang ringan. Kabar baiknya, server Debian, Ubuntu, dan keluarga RHEL tidak terdampak. Artikel ini menjelaskan cara kerjanya, syarat sebuah server bisa diserang, versi paket yang aman, skrip untuk mengecek, dan cara mencari tanda pembobolan.

Ringkasan cepat

Item	Detail
CVE	CVE-2026-123158 ("sshole")
Produk	OpenSSH (sshd) yang dibangun dengan musl libc tanpa PAM, misalnya paket openssh-server bawaan Alpine Linux
Jenis celah	Bypass autentikasi password
Skor CVSS 3.1	8.1 (tinggi)
Status	Dieksploitasi aktif, masuk CISA KEV 9 November 2026
Versi aman	OpenSSH 10.6p2, atau paket Alpine yang sudah diperbarui (cabang 3.16 sampai edge)
Tidak terdampak	Distro glibc (Debian, Ubuntu, Fedora), sshd dengan PAM, Dropbear, OpenBSD
Penemu	Özgün Kültekin (Wakefield)

Bagaimana celah sshole bekerja?

Celah ini muncul karena tanda gagal dari fungsi hash password di musl kebetulan sama dengan penanda "akun tanpa password" di /etc/shadow. Akibatnya sshd mengira password yang dikirim cocok.

Urutannya seperti ini:

1. Akun yang tidak boleh login dengan password (akun khusus kunci SSH, root, atau user dari direktori) menyimpan karakter * di kolom hash /etc/shadow.
2. Penyerang mencoba login password ke akun tersebut dengan password yang sangat panjang, lebih dari 256 byte.
3. Fungsi crypt() di musl menolak input sepanjang itu dan mengembalikan * sebagai tanda gagal.
4. sshd membandingkan hasil itu dengan isi shadow. Keduanya *, sehingga login diterima.

Kenapa tim OpenSSH tetap menambalnya?

Tim OpenSSH menilai akar masalahnya ada di luar sshd, tetapi karena bisa dieksploitasi lewat sshd, pencegahannya ditambahkan di sana. Catatan rilis 10.6p2 menyebut celah ini memengaruhi sebagian sistem Linux yang dibangun dan dijalankan tanpa dukungan PAM.

Siapa yang terdampak?

Server terdampak bila semua syarat berikut terpenuhi sekaligus:

• sshd dibangun dengan musl libc dan berjalan tanpa PAM. Ini kondisi bawaan paket openssh-server Alpine, atau openssh-server-pam dengan UsePAM no.
• Login password aktif (PasswordAuthentication yes, nilai bawaan OpenSSH).
• Ada akun yang kolom hash-nya hanya berisi *, misalnya user alpine di image cloud resmi Alpine 3.18.11 sampai 3.24.3.
• Ada akun lain di sistem yang punya hash password sungguhan.

Akun root umumnya terlindung oleh PermitRootLogin prohibit-password. Namun user alpine di image cloud resmi bisa menjalankan doas tanpa password, jadi penyerang tetap bisa naik menjadi root. Sistem musl lain seperti OpenWrt, Buildroot, dan Yocto juga perlu dicek. Banyak image Docker populer mematikan login password secara bawaan, sehingga tidak otomatis rentan.

Seberapa serius celah ini?

Sangat serius untuk server yang memenuhi syarat di atas, karena serangan nyata terekam kurang dari sembilan jam setelah CVE dipublikasikan.

• CVSS 3.1: 8.1 (tinggi).
• 5 November 2026: Alpine merilis advisory dan OpenSSH 10.6p2 terbit.
• 6 sampai 7 November: sensor honeypot mencatat percobaan eksploitasi, lalu aktivitas lanjutan berupa pengintaian, pembacaan hash password dan kunci SSH root, serta penambahan kunci ke authorized_keys. Ada juga laporan pemasangan penambang kripto dan bot.
• 9 November: CISA menambahkannya ke KEV dengan tenggat 12 November untuk instansi sipil federal AS.
• Kode proof-of-concept beredar di GitHub. Sebagian belum terverifikasi dan bisa berisi malware, jadi jangan menjalankannya di mesin kerja.

Versi mana yang aman?

Versi yang aman adalah OpenSSH 10.6p2 ke atas, atau paket openssh Alpine dengan revisi berikut per cabang:

Cabang Alpine	Paket openssh yang sudah diperbaiki
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

Alpine di bawah 3.16 tidak mendapat paket perbaikan. Untuk versi itu, mematikan login password adalah satu-satunya jalan sampai sistem dimigrasikan.

Bagaimana cara cek apakah server saya terdampak?

Jalankan skrip berikut sebagai root. Skrip hanya membaca konfigurasi dan tidak mengubah apa pun. Logikanya sudah diuji di sandbox dengan keluaran tiruan untuk kondisi rentan dan tidak rentan.

#!/bin/sh
# Cek paparan CVE-2026-123158 (sshole). Hanya membaca, tidak mengubah apa pun.
libc="glibc/lainnya"
if ldd --version 2>&1 | grep -qi musl || ls /lib/ld-musl-* >/dev/null 2>&1; then libc="musl"; fi
echo "libc           : $libc"
command -v apk >/dev/null 2>&1 && echo "paket openssh  : $(apk info -v 2>/dev/null | grep -E '^openssh-server(-pam)?-[0-9]' | tr '\n' ' ')"
command -v sshd >/dev/null 2>&1 || { echo "sshd tidak terpasang: tidak terdampak"; exit 0; }
echo "versi sshd     : $(sshd -V 2>&1 | head -n1)"
cfg=$(sshd -T 2>/dev/null | grep -iE '^(passwordauthentication|usepam) ')
echo "$cfg" | sed 's/^/konfigurasi    : /'
pw=$(echo "$cfg" | awk '$1=="passwordauthentication"{print $2}')
pam=$(echo "$cfg" | awk '$1=="usepam"{print $2}')
if [ "$libc" = "musl" ] && [ "$pw" != "no" ] && [ "$pam" != "yes" ]; then
  echo "HASIL: BERISIKO. Update paket openssh lalu restart sshd."
else
  echo "HASIL: kombinasi rentan (musl + tanpa PAM + login password) tidak ditemukan."
fi

Untuk image container, cek versi paket di dalam image, lalu bandingkan dengan tabel di atas:

docker run --rm --entrypoint sh NAMA_IMAGE -c 'cat /etc/alpine-release; apk info -v 2>/dev/null | grep openssh'

Bagaimana cara update dengan aman?

Cara amannya: tutup dulu login password, perbarui paket, lalu restart sshd. Tanpa restart, proses sshd lama tetap melayani koneksi.

Langkah 1: mitigasi cepat

Pastikan login dengan kunci SSH sudah berfungsi, lalu matikan login password. Biarkan satu sesi SSH tetap terbuka sampai Anda yakin bisa masuk lagi.

# /etc/ssh/sshd_config
PasswordAuthentication no

# uji konfigurasi, lalu restart
sshd -t && rc-service sshd restart

Langkah 2: update dan verifikasi

apk upgrade -U -a
rc-service sshd restart

# verifikasi versi paket dan konfigurasi aktif
apk info -v | grep openssh
sshd -T | grep -iE 'passwordauthentication|usepam'

Untuk container, bangun ulang image dari base Alpine terbaru dan deploy ulang. Menjalankan apk upgrade di container yang sedang hidup akan hilang saat container dibuat ulang.

Bagaimana cara mendeteksi tanda pembobolan?

Tanda utamanya adalah login password yang berhasil ke akun yang seharusnya tidak punya password. Cari di log sistem:

# login password yang diterima (Alpine: /var/log/messages)
grep -h "Accepted password for" /var/log/messages* 2>/dev/null

# akun yang tidak punya hash password (kolom kedua "*" atau "!")
awk -F: '$2 ~ /^[*!]/ {print $1}' /etc/shadow

# perubahan terbaru pada kunci SSH dan pemakaian doas
find / -name authorized_keys -mtime -14 2>/dev/null
grep -h "doas" /var/log/messages* 2>/dev/null | tail -n 50

Kalau sebuah akun muncul di kedua daftar pertama (login password diterima, padahal tidak punya hash), anggap server sudah dibobol.

Kalau menemukan tanda pembobolan?

1. Isolasi server dari jaringan, tetapi jangan langsung dimatikan bila Anda perlu bukti forensik.
2. Periksa authorized_keys semua user, user baru, cron, dan proses yang tidak dikenal.
3. Rotasi semua kunci SSH, token, dan kredensial cloud yang tersimpan di server itu dari mesin lain yang tepercaya.
4. Bangun ulang server dari image bersih yang sudah ditambal. Membersihkan manual berisiko meninggalkan backdoor.

Pertanyaan yang sering diajukan

Apakah server Ubuntu atau Debian saya terdampak?

Tidak. Distro berbasis glibc seperti Debian, Ubuntu, dan Fedora tidak terdampak, begitu juga sshd yang memakai PAM. Celah ini spesifik pada kombinasi musl libc dan sshd tanpa PAM.

Saya hanya memakai Alpine sebagai base image Docker tanpa sshd. Perlu khawatir?

Tidak untuk celah ini. Serangan butuh sshd yang berjalan dan bisa dijangkau. Tetap perbarui base image agar paket lain ikut mutakhir.

Apakah cukup menjalankan apk upgrade?

Belum. Setelah paket diperbarui, sshd harus di-restart. Proses lama tetap memakai biner rentan sampai layanan dimulai ulang.

Apakah mengganti port SSH membantu?

Tidak menutup celah. Mengganti port hanya mengurangi pemindaian otomatis. Perbaikan yang benar adalah update paket atau mematikan login password.

Apakah root bisa langsung diambil alih?

Biasanya tidak secara langsung, karena PermitRootLogin prohibit-password adalah nilai bawaan. Risiko terbesar ada pada akun khusus kunci yang punya akses doas atau sudo tanpa password.

Baca juga celah lain yang sedang aktif diserang: celah update WordPress CVE-2026-119977, celah Git CVE-2026-111760, dan kasus backdoor SSH lewat ekstensi editor palsu.

Sumber

• OpenSSH: catatan rilis 10.6p2 (5 November 2026)
• CISA: Adds Four Known Exploited Vulnerabilities to Catalog (9 November 2026)
• Help Net Security: OpenSSH flaw exploited in the wild just hours after disclosure
• The Hacker News: CISA Warns of Active Exploitation of OpenSSH, GPUStack, FreeSWITCH, and IBM Flaws
• Cycode: sshole (CVE-2026-123158), OpenSSH password bypass on Alpine Linux