SSHole: Celah OpenSSH yang Membuka Akun Tanpa Password

Verdict Cepat

Verdict cepat: SSHole (CVE-2026-123158) adalah celah bypass autentikasi di OpenSSH yang memungkinkan login ke akun tanpa password dengan cara mengirim password yang sengaja dibuat sangat panjang. Celah ini nyata, sudah dieksploitasi, dan sudah masuk katalog CISA Known Exploited Vulnerabilities. Kabar baiknya, cakupannya sempit: hanya sistem Linux berbasis musl tanpa PAM, terutama Alpine Linux, yang terdampak. Server Debian, Ubuntu, dan RHEL aman. Jika ada server Alpine yang menjalankan sshd dengan login password aktif, tambal sekarang, atau matikan login password hari ini juga.

Apa Itu SSHole dan Kenapa Ramai Dibicarakan

Pada 5 November, OpenSSH merilis Portable OpenSSH 10.6p2 untuk menutup celah autentikasi yang ditemukan peneliti keamanan Özgün Kültekin dari Wakefield. Celah itu diberi nama SSHole dan nomor CVE-2026-123158, dengan skor CVSS 8.1. Dalam hitungan jam setelah pengumuman, firma intelijen ancaman Previdian mencatat percobaan eksploitasi pertama, kurang dari sembilan jam setelah publikasi, dan mengonfirmasi akses root pada honeypot Alpine Linux. Pada 9 November, CISA memasukkan CVE ini ke katalog Known Exploited Vulnerabilities, yang berarti ada bukti eksploitasi di dunia nyata, dan instansi sipil federal Amerika Serikat wajib menambal atau menerapkan mitigasi paling lambat 12 November.

Yang membuat celah ini menarik untuk dibahas bukan sekadar skornya. SSHole adalah bug logika, bukan kerusakan memori. Tidak ada buffer overflow, tidak ada kriptografi yang dipatahkan. Celah ini lahir dari pertemuan tiga keputusan rekayasa yang masing-masing masuk akal pada masanya, tetapi bersama-sama membuka pintu. Saya menilai kasus ini sebagai pengingat bahwa kegagalan paling berbahaya sering kali bersembunyi di sambungan antar komponen, bukan di dalam satu komponen saja.

Perilakunya mudah dijelaskan. Pada sistem yang terdampak, penyerang yang bisa menjangkau port SSH dapat masuk ke akun yang tidak memiliki password, cukup dengan mengirim password sepanjang 257 sampai 1024 byte. Tidak perlu kunci SSH, tidak perlu menebak password, tidak perlu kredensial curian. Satu koneksi sudah cukup, dan menurut advisory Alpine, serangan ini berhasil setiap kali dicoba pada sistem yang memenuhi syarat.

Cara Kerja Celah Ini

Untuk memahami SSHole, perlu melihat cara OpenSSH memeriksa password saat PAM tidak digunakan. Tanpa PAM, sshd memanggil fungsi crypt() untuk mengubah password yang diketik menjadi hash, lalu membandingkan hasilnya dengan nilai yang tersimpan di berkas /etc/shadow. Akun yang tidak memiliki password menyimpan tanda bintang (*) pada kolom password. Tanda itu seharusnya berarti tidak ada password yang valid, sehingga login password ke akun tersebut mustahil.

Masalah muncul pada implementasi crypt() di musl, pustaka C yang dipakai Alpine Linux. Untuk hash SHA-256 dan SHA-512, crypt() di musl menolak input lebih panjang dari 256 byte. Saat menerima password sepanjang itu, fungsi tersebut gagal dan mengembalikan string “*” sebagai penanda error. Di sinilah perbandingan yang dilakukan sshd berubah menjadi bumerang: sshd membandingkan “*” hasil crypt() dengan “*” yang tersimpan di shadow, menemukan dua nilai yang identik, lalu menganggap autentikasi berhasil.

Batas atas 1024 byte muncul karena sshd membuang password yang lebih panjang dari itu sebelum diproses. Jadi rentang yang berfungsi adalah 257 sampai 1024 byte. Perbaikan di OpenSSH 10.6p2 pun tergolong sempit dan tepat sasaran: sshd kini menolak hash tersimpan yang panjangnya kurang dari empat karakter, apa pun yang dikembalikan crypt(). Dengan begitu, tanda “*” tidak lagi bisa lolos sebagai hash yang valid.

Baca juga:

Ekstensi Cursor Disusupi: Marketplace Bukan Zona Aman

Analisis mendalam dari Hawk-Eye menjelaskan bahwa perilaku ini melibatkan tiga keputusan yang diambil dalam rentang empat belas tahun. Akarnya dapat dilacak ke tambalan tahun 2016 untuk CVE-2016-6210, celah enumerasi nama pengguna, yang mengubah cara OpenSSH menangani error verifikasi password pada musl. Tambalan itu menutup satu celah, tetapi tanpa disadari menyiapkan celah lain yang baru terlihat satu dekade kemudian.

Siapa yang Terdampak dan Siapa yang Aman

Celah ini hanya bisa dipakai bila empat syarat terpenuhi sekaligus. Jika satu saja tidak terpenuhi, CVE ini tidak dapat dieksploitasi pada sistem tersebut. Syarat pertama, sshd dibangun dengan musl libc. Kasus paling umum adalah Alpine Linux, dan laporan juga menyebut OpenWrt, Buildroot, serta build Yocto. Syarat kedua, PAM tidak dipakai untuk memeriksa password. Paket openssh-server bawaan Alpine memang dibangun tanpa PAM, dan paket openssh-server-pam yang dijalankan dengan UsePAM no juga masuk kategori ini.

Syarat ketiga, login password masih aktif, yang merupakan bawaan OpenSSH. Syarat keempat, ada akun dengan kolom password “*” dan setidaknya satu akun lain yang memiliki hash $5$ atau $6$ yang asli. Detail terakhir ini penting: satu pengguna dengan password asli membuat setiap akun tanpa password pada mesin yang sama menjadi bisa dijangkau. Akun root biasanya selamat karena bawaan OpenSSH adalah PermitRootLogin prohibit-password, tetapi akun lain tanpa password tidak memiliki perlindungan itu.

Perbedaan perilaku glibc menjelaskan kenapa distribusi besar selamat. Pada glibc, crypt() yang gagal mengembalikan pointer null atau token *0, dan keduanya tidak bisa sama dengan tanda “*” yang tersimpan. sshd pun sudah menolak nilai tersebut. Kepemilikan cacat ini sendiri masih diperdebatkan: OpenSSH sudah merilis perbaikan, sementara pengelola musl menilai masalahnya ada pada pemakaian crypt() yang keliru oleh pemanggil, bukan cacat di musl. Musl berencana mengubah mekanisme itu pada rilis mendatang.

Seberapa Nyata Ancaman Ini

Pertanyaan yang wajar setelah membaca syarat yang panjang adalah apakah celah ini benar-benar dieksploitasi, atau hanya menarik secara teori. Jawabannya sudah berubah dalam hitungan hari. Laporan awal pada 6 November menyebut belum ada eksploitasi terkonfirmasi di dunia nyata dan CVE ini belum masuk katalog CISA. Pada 9 November, CISA menambahkannya ke katalog tersebut. Sehari kemudian, Ars Technica melaporkan eksploitasi aktif, dengan firma GreyNoise mencatat serangan terhadap honeypot di Asia Tenggara oleh kelompok yang dilacak sebagai GT10, termasuk apa yang disebut sebagai intrusi matang dan pemasangan backdoor bernama TAC Agent.

Skala permukaan serangannya besar, meski hanya sebagian kecil yang memenuhi semua syarat. Firma Detectify, dikutip Ars Technica, menyebut Shodan mencatat sekitar 22 juta sistem dengan SSH terbuka di port 22. Ars menilai hanya sebagian kecil yang memenuhi kondisi SSHole, tetapi menguji tiap sistem itu cepat dan mudah, sehingga menemukan perangkat yang rentan tidak memerlukan banyak usaha.

Di sinilah konteks container menjadi penting. Alpine adalah basis image container yang sangat populer, dan image dasarnya di Docker Hub sudah diunduh lebih dari satu miliar kali. Advisory Alpine menegaskan pengguna container yang tidak menjalankan sshd di dalam container tidak terdampak. Ancaman terbesar justru ada pada pola yang jarang disadari: image cloud berbasis Alpine, perangkat embedded, dan container yang menjalankan server SSH di dalamnya. Orang yang paling berisiko sering kali tidak sadar sedang menjalankan layanan yang terekspos.

Baca juga:

Retak di Balik Booming Belanja AI: Siapa yang Bayar?

Akar Masalah: Tiga Keputusan yang Bertemu

SSHole layak dibaca sebagai studi kasus rekayasa, bukan sekadar berita celah. Keputusan pertama adalah pilihan musl untuk mengembalikan “*” sebagai penanda error dari crypt(). Pilihan ini masuk akal sebagai konvensi internal, tetapi nilai yang dipilih ternyata bermakna dalam konteks lain, yaitu sebagai penanda akun tanpa password di shadow.

Keputusan kedua adalah cara sshd memeriksa hasil crypt() tanpa memvalidasi apakah nilai yang dikembalikan merupakan hash yang sah atau sekadar penanda error. Selama input berada dalam batas normal, perbedaan itu tidak pernah terlihat. Keputusan ketiga adalah tambalan tahun 2016 untuk CVE-2016-6210, yang mengubah penanganan error verifikasi password dan tanpa sengaja menciptakan jalur tempat dua nilai “*” bisa bertemu.

Pola seperti ini pernah muncul pada insiden lain yang dibahas di Grafisify. Pada anatomi PHP2Shell, dua celah kritis PHP bertemu dan mengancam jutaan situs. Pada insiden sertifikat emSign, satu rantai kepercayaan yang retak memaksa pembaruan darurat. SSHole mengikuti pola yang sama: bukan satu kesalahan besar, melainkan beberapa asumsi kecil yang saling menguatkan.

Cara Memeriksa dan Menambal Sistem

Langkah pertama adalah memastikan apakah ada sistem yang memenuhi keempat syarat. Periksa distribusi dan pustaka C yang dipakai, periksa apakah sshd dibangun dengan PAM, dan periksa konfigurasi dengan perintah sshd -T untuk melihat nilai UsePAM dan PasswordAuthentication. Setelah itu, periksa berkas /etc/shadow untuk mencari akun dengan kolom password “*”. Akun seperti ini umum pada pengguna yang hanya memakai kunci SSH, pengguna direktori tanpa entri shadow, dan root pada image dasar.

Jika sistem memakai Alpine, perbarui paket openssh ke build yang sudah diperbaiki lalu restart sshd. Alpine merilis perbaikan pada hari yang sama dengan pengumuman, dengan versi 10.6_p2-r0 untuk edge, 10.3_p1-r2 untuk 3.24, 10.2_p1-r1 untuk 3.23, dan 10.0_p1-r11 untuk 3.22, plus backport ke setiap branch dari 3.21 sampai 3.16. Perlu dicatat, Alpine 3.21 mencapai akhir dukungan pada 1 November, jadi pengguna branch itu sebaiknya naik ke branch yang masih didukung. Panduan dari ComputingForGeeks dan Safeguard merinci perintah pengecekan dan penambalan untuk host maupun image container, termasuk cara memverifikasi build yang terpasang.

Bila penambalan belum bisa dilakukan, mitigasi tercepat adalah mematikan login password dengan mengatur PasswordAuthentication no di sshd_config, lalu restart sshd. Langkah ini menutup jalur serangan sepenuhnya karena celah ini hanya hidup lewat autentikasi password. Alternatif lain adalah membatasi akses SSH ke alamat IP tertentu lewat firewall, atau memindahkan layanan SSH dari port bawaan bila itu bagian dari kebijakan yang sudah ada. Saya menyarankan untuk tidak mengandalkan pemindahan port sebagai satu-satunya pertahanan, karena pemindai internet menemukan layanan di port nonstandar dengan mudah.

Setelah menambal, periksa log autentikasi. Cari login yang berhasil ke akun yang seharusnya tanpa password, terutama yang terjadi setelah 5 November. Perhatikan juga login dari alamat IP yang tidak dikenal pada akun kunci saja. Jika ada indikasi akses yang tidak sah, anggap sistem sudah dikompromikan dan lakukan respons insiden penuh, bukan sekadar menambal. CISA memberi tenggat 12 November bagi instansi federal, tetapi tenggat itu bukan alasan menunda bagi siapa pun yang menjalankan server Alpine yang terekspos ke internet.

Baca juga:

Agen AI yang Bermain Sendiri Saat Ditinggal

Kesalahan Umum yang Perlu Dihindari

Kesalahan pertama adalah menganggap celah ini tidak relevan karena memakai container. Benar bahwa container Alpine tanpa sshd aman, tetapi image dasar yang sama sering dipakai sebagai fondasi image lain, dan satu image turunan yang menjalankan sshd sudah cukup. Audit perlu mencakup image yang dibangun di atas Alpine, bukan hanya host yang menjalankan Alpine secara langsung. Hal yang sama berlaku untuk perangkat embedded dan router yang memakai OpenWrt dengan server SSH yang diinstal manual.

Kesalahan kedua adalah mengandalkan firewall sebagai pengganti tambalan. Firewall mengurangi permukaan serangan, tetapi satu aturan yang salah, satu port yang terbuka untuk keperluan darurat, atau satu layanan yang dipindahkan ke jaringan lain bisa membuka kembali jalurnya. Penambalan adalah perbaikan permanen, sementara firewall adalah lapisan tambahan. Keduanya perlu jalan bersama, bukan saling menggantikan.

Kesalahan ketiga adalah berasumsi akun root aman berarti seluruh sistem aman. Bawaan PermitRootLogin prohibit-password memang melindungi root, tetapi akun layanan, akun deployment, dan akun pengguna lain tanpa password tetap bisa dimasuki, dan dari sana penyerang dapat mencari jalan eskalasi hak akses. Dalam kasus honeypot yang dilaporkan Previdian, akses root berhasil dicapai, yang menunjukkan bahwa perlindungan root saja tidak cukup bila akun lain terbuka.

Kesalahan keempat adalah menunda karena merasa celah ini terlalu sempit untuk dikejar penyerang. Bukti yang muncul dalam beberapa hari membantah anggapan itu. Percobaan eksploitasi tercatat kurang dari sembilan jam setelah publikasi, kode proof of concept tersedia secara publik, dan kelompok GT10 dilaporkan melakukan intrusi matang terhadap honeypot. Penyerang tidak perlu menargetkan satu organisasi secara khusus, karena pemindaian otomatis dapat menguji jutaan alamat dan menyaring mana yang memenuhi syarat. Saya melihat pola ini berulang pada setiap celah dengan eksploitasi yang mudah: syarat yang sempit tidak menghentikan pemindaian massal.

Terakhir, jangan abaikan pesan yang lebih luas dari insiden ini. Praktik yang sama, yaitu menganggap akun tanpa password sebagai akun yang tertutup, berlaku di banyak sistem lain. Artikel tentang agen AI yang bisa login tanpa tahu password membahas risiko serupa dari sisi yang berbeda. Prinsipnya sama: akun yang tidak dimaksudkan untuk login password harus benar-benar tidak bisa dipakai untuk login password, dengan konfigurasi yang eksplisit, bukan dengan mengandalkan nilai penanda yang kebetulan tidak pernah bentrok.

Kesimpulan dan CTA

SSHole adalah celah yang sempit tetapi serius. Cakupannya terbatas pada sistem musl tanpa PAM, tetapi di dalam cakupan itu dampaknya total: login tanpa password, tanpa kunci, dalam satu koneksi. Bukti eksploitasi aktif sudah ada, CISA sudah memasukkannya ke katalog kerentanan yang diketahui dieksploitasi, dan kode proof of concept beredar secara publik. Bagi pengguna Debian, Ubuntu, dan RHEL, kabar baiknya adalah tidak ada tindakan yang diperlukan. Bagi pengguna Alpine dan sistem musl lain, tindakannya jelas dan mendesak.

Perbarui OpenSSH ke 10.6p2 atau build backport yang setara, restart sshd, dan matikan login password bila tidak diperlukan. Periksa log untuk login yang mencurigakan setelah tanggal pengumuman. Jika ragu apakah ada sistem yang terdampak, perlakukan setiap image berbasis Alpine yang menjalankan sshd sebagai terdampak sampai terbukti sebaliknya. Celah yang lahir dari pertemuan tiga keputusan masuk akal ini mengingatkan bahwa keamanan bukan soal satu komponen yang benar, melainkan soal semua komponen yang sepakat tentang arti sebuah kegagalan.

Untuk konteks keamanan yang lebih luas, insiden ini layak dibaca bersama liputan lain di Grafisify. Kasus ekstensi Cursor yang disusupi menunjukkan bahwa rantai pasokan perangkat lunak bisa retak dari arah yang tidak terduga. SSHole menunjukkan hal yang sama pada lapisan infrastruktur: kepercayaan yang dibangun di atas asumsi yang tidak pernah diuji bersama akan runtuh pada saat yang paling tidak diharapkan. Tambal sekarang, audit setelahnya, dan jadikan pengecekan akun tanpa password sebagai bagian rutin dari hardening server.