Waspada CVE-2026-46333: Celah Kernel Linux 'ssh-keysign-pwn' dan Cara Mengatasinya
Belum genap sebulan terakhir, komunitas Linux sudah dihadapkan dengan beberapa celah keamanan serius di kernel. Kali ini ada satu lagi yang perlu langsung kamu tangani: CVE-2026-46333, yang dikenal juga dengan nama ssh-keysign-pwn atau ptrace exit-race.
Celah ini bukan sekadar teori. Public exploit-nya sudah beredar, dan siapa pun yang punya akses shell di server kamu berpotensi membaca file sensitif seperti SSH host private key dan /etc/shadow tanpa perlu jadi root. Mengingat krusialnya keamanan kunci akses ini, pastikan Anda juga sudah mengikuti panduan cara menggunakan SSH Key untuk akses VPS agar server tidak sekadar bergantung pada password.
Pada artikel ini, CloudKilat akan menjelaskan apa yang terjadi pada celah keamanan ini dan apa yang perlu kamu lakukan sekarang.
Apa Itu CVE-2026-46333 (ssh-keysign-pwn)#
CVE-2026-46333 adalah celah pada jalur pengecekan akses ptrace di kernel Linux, tepatnya di fungsi __ptrace_may_access(). Celah ini ditemukan oleh tim Qualys dan dilaporkan langsung ke security@kernel.org. Fix-nya sudah di-push oleh Linus Torvalds pada 14 Mei 2026 melalui commit 31e62c2ebbfd.
Masalahnya ada di urutan operasi saat sebuah proses keluar (exit). Kernel menjalankan exit_mm() sebelum exit_files(), sehingga ada jendela waktu sempit di mana:
- Proses privileged sudah melepas memory descriptor (
mm = NULL), tapi - File descriptor-nya masih terbuka.
Di kondisi ini, pengecekan dumpable di __ptrace_may_access() terlewati karena mm sudah NULL. Akibatnya, proses lain yang tidak punya hak istimewa bisa memanfaatkan syscall pidfd_getfd(2) untuk "mencuri" file descriptor dari proses privileged yang sedang keluar tadi.
Target yang paling dieksploitasi saat ini adalah dua binary SUID:
ssh-keysign: membuka SSH host private key sebelum melepas privileges.chage: membuka/etc/shadowsebelum melepas privileges.
🚨 Public Exploit Sudah Ada
Peneliti keamanan dengan handle "_SiCk" sudah mempublikasikan dua exploit yang bekerja: satu untuk membaca SSH host private key viassh-keysign, satu lagi untuk membaca/etc/shadowviachage -l. Jangan tunda mitigasi.
Siapa yang Terdampak?#
Celah keamanan ini memengaruhi berbagai distribusi Linux populer, terutama yang menggunakan kernel versi 4.18 ke atas. Berikut adalah status dampak untuk beberapa distro yang umum digunakan:
| Versi | Status |
|---|---|
| AlmaLinux 9 & 10 | Rentan, public exploit bekerja langsung |
| AlmaLinux 8 | Bug ada, tapi public PoC belum bisa dieksploitasi secara langsung |
| CloudLinux 8 LTS | Rentan, public exploit bekerja langsung |
| CloudLinux 9 & 10 | Rentan, public exploit bekerja langsung |
| CloudLinux 7h & 8 | Bug ada, tapi public PoC belum bisa dieksploitasi (syscall pidfd_getfd tidak tersedia di kernel 4.18) |
| CloudLinux 7 | Tidak terdampak (kernel 3.10 lebih lawas dari titik munculnya bug ini) |
⚠️ Catatan untuk CloudLinux 7h, CloudLinux 8, dan AlmaLinux 8
Meskipun public exploit saat ini belum berhasil di versi-versi ini, bug dasarnya tetap ada di kernel 4.18. Komunitas keamanan sedang menyiapkan exploit adaptasi viaptrace_attachlangsung. Tetap lakukan mitigasi sekarang.
Cara Mengatasi CVE-2026-46333#
Patch kernel resmi sudah tersedia di repository production. Ada tiga cara yang bisa kamu pilih sesuai kebutuhan dan kondisi server.
Cara 1: Update Kernel dari Production Repo (Perlu Reboot)#
Cara ini adalah solusi permanen yang direkomendasikan. Patch sudah masuk ke repository production sejak 16 Mei 2026, jadi prosesnya sekarang jauh lebih simpel: cukup update dan reboot.
Langkah 1: Update metadata dan kernel
sudo dnf clean metadata && sudo dnf upgrade
Langkah 2: Reboot server
sudo reboot
Langkah 3: Verifikasi versi kernel
Setelah server kembali online, cek versinya dengan:
uname -r
Bandingkan dengan versi target berikut:
| Versi OS | Target Kernel |
|---|---|
| AlmaLinux 8 | 4.18.0-553.124.4.el8_10 |
| AlmaLinux 9 | 5.14.0-611.54.6.el9_7 |
| AlmaLinux 10 | 6.12.0-124.56.5.el10_1 |
⚠️ Update belum muncul?
Sebagian mirror memiliki frekuensi sinkronisasi sekitar 3 jam. Kalau perintah di atas belum mengambil kernel yang sudah dipatch, tunggu sekitar satu jam lalu coba lagi.
💡 Patch Ganda dalam Satu Reboot
Kernel dari production repo ini sudah menyertakan patch untuk Fragnesia (CVE-2026-46300) sekaligus. Jadi satu kali reboot, dua celah selesai ditangani.
Cara lama via Testing Repo (untuk referensi)
Instruksi berikut adalah metode lama yang digunakan sebelum patch masuk ke production. Tidak lagi direkomendasikan, tapi tetap disertakan sebagai referensi.
Aktifkan testing repository
Untuk AlmaLinux 8, 9 atau CloudLinux 9:
sudo dnf install -y almalinux-release-testing
Untuk AlmaLinux 10 atau CloudLinux 10 (install manual dari URL):
sudo dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
Update kernel
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
Nonaktifkan testing repository setelah reboot
sudo dnf config-manager --disable almalinux-testing
Cara 2: Mitigasi Sementara via ptrace_scope (Tanpa Reboot)#
Kalau kamu tidak bisa melakukan reboot sekarang, opsi ini bisa jadi jembatan sementara yang efektif. Caranya adalah memperketat izin ptrace lewat Yama LSM, sehingga exploit yang ada saat ini tidak bisa berjalan.
Terapkan sekarang (langsung aktif, tanpa reboot):
sudo sysctl -w kernel.yama.ptrace_scope=3
Buat permanen agar tidak hilang setelah reboot:
echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-cve-2026-46333.conf
Khusus untuk CloudLinux, tersedia sysctl tambahan yang lebih spesifik untuk menonaktifkan ptrace di level kernel:
sudo sysctl -w kernel.user_ptrace=0
echo 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-ptracenull.conf
sudo sysctl --system
⚠️ Perhatikan Efek Samping dan Pilihan Nilainya
Denganptrace_scope=3, user biasa tidak bisa lagi melakukan attach debugger sepertigdb -pataustrace -pke proses yang sedang berjalan. Di lingkungan shared hosting biasa, ini umumnya tidak bermasalah. Tapi kalau server dipakai untuk development atau CI/CD, pertimbangkan nilaiptrace_scope=2sebagai kompromi: hanya admin (root) yang bisa attach ke proses lain, tapi semua public exploit yang diketahui saat ini tetap terblokir.
ℹ️ Ini Mitigasi, Bukan Fix Permanen
Cara 2 hanya memblokir exploit yang diketahui saat ini. Jalur lain ke bug yang sama bisa saja ada. Tetap rencanakan update kernel dan reboot begitu ada kesempatan.
Cara 3: KernelCare Livepatch (Tanpa Reboot, Khusus CloudLinux)#
Kalau server kamu menggunakan CloudLinux dengan KernelCare, ada opsi yang lebih nyaman: livepatch otomatis. KernelCare menerapkan patch keamanan langsung ke kernel yang sedang berjalan, tanpa perlu reboot dan tanpa maintenance window.
Begitu livepatch untuk CVE-2026-46333 dirilis oleh tim CloudLinux, server yang sudah menggunakan KernelCare akan mendapatkannya secara otomatis. Kamu tidak perlu melakukan apa pun secara manual.
Untuk memastikan livepatch sudah terpasang, cek status KernelCare dengan:
kcarectl --info
🔧 CageFS sebagai Lapisan Perlindungan Tambahan
Bagi pengguna CloudLinux di lingkungan shared hosting, mengaktifkan CageFS menambahkan lapisan isolasi yang memblokir eksploitasi celah ini, bahkan tanpa perubahan sysctl apapun. CageFS mengisolasi setiap tenant di filesystem virtualnya sendiri, sehingga proses antar user tidak bisa saling "melihat". Kalau CageFS belum aktif di server kamu, ini saat yang tepat untuk mengaktifkannya.
Cara Mengembalikan Pengaturan Setelah Patch Terpasang#
Setelah kernel yang sudah dipatch berhasil diinstall dan server sudah reboot, kamu bisa mengembalikan pengaturan ptrace ke kondisi semula:
# Hapus file konfigurasi sysctl
sudo rm /etc/sysctl.d/99-cve-2026-46333.conf
sudo rm /etc/sysctl.d/99-ptracenull.conf
# Aktifkan kembali ptrace
sudo sysctl -w kernel.yama.ptrace_scope=0
sudo sysctl -w kernel.user_ptrace=1
Kesimpulan#
CVE-2026-46333 adalah celah serius dengan public exploit yang sudah beredar, tapi penanganannya cukup jelas. Patch sudah ada di repository production, jadi kalau kamu bisa reboot sekarang, pilih Cara 1 untuk solusi permanen dengan dua perintah saja. Kalau tidak bisa, terapkan Cara 2 sebagai tameng sementara sambil menunggu jadwal maintenance. Pengguna CloudLinux dengan KernelCare bisa mengandalkan Cara 3 untuk perlindungan otomatis tanpa reboot.
Tetap waspada dan jangan tunda patch keamanan!
Referensi:
