Valkey 9.1.3: Heap Overflow di Pub/Sub Cluster Sudah Ditambal

Valkey 9.1.3 dirilis 26 Oktober 2026 dengan label urgensi SECURITY, karena menambal satu heap buffer overflow pada konstruksi pesan Pub/Sub cluster yang oleh catatan rilis disebut bisa membuat klien terautentikasi mengeksekusi kode arbitrer lewat pesan berukuran berlebih. Celah itu terdaftar sebagai GHSA-f4q9-j22m-xqq9 dan diperbaiki lewat PR #5030. Selain keamanan, ada belasan perbaikan konsistensi replikasi, ekspirasi, dan module API yang ikut masuk di rilis ini.

TL;DR

• Valkey 9.1.3 keluar 26 Oktober 2026, urgensi upgrade ditandai SECURITY.
• Celahnya heap buffer overflow di Pub/Sub cluster, advisory GHSA-f4q9-j22m-xqq9, perbaikan di PR #5030.
• Butuh klien yang sudah terautentikasi dan mengirim pesan berukuran berlebih, jadi bukan celah tanpa syarat.
• Bug stream command tidak memicu WATCH dan client-side tracking ikut diperbaiki.
• Ada perbaikan busy-spin event loop di mesin virtual yang memakai clocksource non-tsc.

Seberapa serius celah di Valkey 9.1.3?

Catatan rilis memakai frasa upgrade urgency SECURITY, frasa tertinggi dalam skema penandaan mereka, dan menyebut dampak potensial berupa eksekusi kode arbitrer. Itu membuatnya serius, tapi syaratnya dua: penyerang harus sudah punya kredensial yang sah, dan harus bisa mengirim pesan Pub/Sub berukuran berlebih ke klaster.

Dua syarat itu penting untuk menakar risiko, bukan untuk menyepelekannya. Layanan yang membuka port Valkey ke jaringan luas tanpa autentikasi kuat sudah punya masalah lebih besar daripada celah ini. Sebaliknya, lingkungan multi-tenant yang memberi banyak tim akses Pub/Sub punya permukaan serangan nyata, karena satu klien yang sah sudah cukup.

Yang tidak dicantumkan di catatan rilis: rentang versi terdampak secara rinci dan skor CVSS. Untuk keduanya, advisory GHSA-f4q9-j22m-xqq9 adalah rujukan yang benar, bukan ringkasan dari artikel ini.

Apa saja perbaikan selain keamanan?

Perbaikan terbanyak ada di konsistensi antara primary dan replika, area yang gejalanya jarang terlihat langsung. Berikut ringkasan yang paling berdampak bagi operasi harian.

Area	Perubahan	Dampak praktis
Stream dan tracking	XGROUP, XSETID, XREADGROUP, XACK, XCLAIM, XAUTOCLAIM kini memicu WATCH dan invalidasi tracking	Cache sisi klien tidak lagi menyajikan data basi setelah consumer group berubah
Module API	Deklarasi fungsi dikoreksi agar mengembalikan int	Menghilangkan undefined behavior di platform yang memeriksa tanda tangan fungsi
Ekspirasi	Waktu kedaluwarsa relatif yang meluap ditolak	Mencegah server abort karena nilai expire negatif
Hash	COPY menyertakan field kedaluwarsa yang belum dibersihkan	Penghapusan ikut tereplikasi, replika tidak menyimpang

Ada juga perbaikan yang menyentuh mesin virtual: event loop tidak lagi busy-spin ketika kernel memakai clocksource selain tsc, karena penggunaan raw TSC untuk jam monotonik diganti. Gejala versi lama adalah CPU satu inti penuh tanpa beban kerja berarti, khas pada VM dengan virtualisasi tertentu dan sering disalahartikan sebagai masalah konfigurasi.

Kapan harus upgrade dan bagaimana urutannya?

Segera, kalau instalasimu memakai Pub/Sub di mode cluster dan menerima koneksi dari banyak klien. Kalau Valkey hanya dipakai sebagai cache internal dengan satu aplikasi dan jaringan tertutup, urgensinya turun, tapi tetap masuk jadwal pemeliharaan terdekat.

1. Baca advisory GHSA-f4q9-j22m-xqq9 dan pastikan versi yang berjalan masuk daftar terdampak.
2. Ambil snapshot atau AOF terbaru sebelum menyentuh node mana pun.
3. Upgrade replika lebih dulu, satu per satu, lalu lakukan failover terkontrol ke replika yang sudah baru.
4. Upgrade node primary terakhir, setelah replika utama sudah berjalan di 9.1.3.
5. Periksa valkey-check-aof pada salinan AOF, karena rilis ini juga memperbaiki deteksi tanda tangan RDB pada AOF multipart.

Langkah kelima kerap dilewati padahal murah. Kalau AOF multipart-mu valid tetapi dilaporkan rusak oleh alat versi lama, itu masalah alat, bukan data. Setelah naik, laporkan ulang supaya kamu tidak melakukan pemulihan yang tidak perlu.

Perubahan mana yang paling berisiko bagi aplikasi?

Perubahan perilaku pada stream command. Selama ini, operasi seperti XACK atau XCLAIM bisa mengubah state consumer group tanpa memicu WATCH maupun invalidasi client-side tracking. Aplikasi yang mengandalkan tracking untuk cache lokal jadi memegang data yang salah tanpa error apa pun.

Setelah upgrade, notifikasi itu benar-benar dikirim. Aplikasi yang menangani invalidasi dengan benar akan langsung membaik. Aplikasi yang selama ini "kebetulan benar" karena tracking tidak pernah aktif bisa menampilkan perilaku berbeda, umumnya lebih sering melakukan refetch. Lonjakan trafik baca setelah upgrade seperti itu normal, bukan regresi.

Yang perlu diwaspadai justru sebaliknya: kalau setelah upgrade pola refetch tidak berubah sama sekali padahal aplikasi memakai tracking, curigai konfigurasi klien yang mematikan fitur tersebut.

Bagaimana memverifikasi bahwa patch ini benar-benar aktif?

Cek versi dari server yang berjalan, bukan dari paket yang terpasang. Pada cluster, lakukan pemeriksaan per node, karena upgrade bergiliran sering meninggalkan satu node tertinggal tanpa terlihat dari layar monitoring yang hanya menampilkan agregat.

Setelah semua node melaporkan 9.1.3, uji tiga hal: publikasi pesan Pub/Sub berukuran normal di dalam cluster, satu siklus consumer group dari XREADGROUP sampai XACK, dan satu operasi RESTORE dari payload yang kamu miliki. Tiga uji itu menutup jalur yang paling banyak berubah di rilis ini tanpa perlu menjalankan beban sintetis besar.

Apakah rilis ini mengubah format data?

Tidak ada perubahan format yang diumumkan. Yang berubah adalah cara beberapa operasi memperlakukan data yang sudah ada, khususnya field hash yang kedaluwarsa tetapi belum dibersihkan, dan penolakan payload RESTORE dengan panjang string yang meluap. Payload semacam itu sekarang ditolak sebagai data rusak, bukan diproses sampai server abort.

Kalau kamu punya pipeline yang menghasilkan payload RESTORE sendiri, uji dulu di lingkungan salinan. Payload yang lolos di versi lama karena kebetulan tidak meluap tetap aman, tetapi validasi yang lebih ketat bisa menolak data yang selama ini diterima.

Perbaikan module API apa yang penting bagi pengembang ekstensi?

Tiga perbaikan menyentuh module API dan semuanya berkaitan dengan kestabilan proses, bukan fitur baru. Pertama, ValkeyModule_HashHasStringRef tidak lagi crash ketika field yang ditanyakan hilang atau sudah kedaluwarsa, dan nilai balik pada API stringRef untuk hash dikoreksi. Sebelumnya, modul yang memeriksa field opsional bisa mematikan server hanya karena field itu tidak ada.

Kedua, perintah tulis dari modul ditolak saat server dijeda untuk penulisan. Ini menutup jalur crash dari callback timer modul ketika CLIENT PAUSE WRITE atau CLUSTER FAILOVER sedang berjalan, situasi yang justru muncul pada momen paling sensitif, yaitu saat failover.

Ketiga, perintah modul yang mengakses key tak terdeklarasi di slot lain kini membaca dan menulis slot yang benar di mode cluster, dan tidak lagi abort di build debug. Kalau kamu merawat modul sendiri, tiga perubahan ini alasan kuat untuk menguji ulang modul terhadap 9.1.3 sebelum menganggapnya aman di produksi.

Apa yang berubah saat failover dan pemulihan?

Ada dua perbaikan yang langsung terasa pada operasi failover. Flag gossip kegagalan primary yang tertinggal di replika sekarang dibersihkan, sehingga failover berikutnya tidak salah melewati jeda pemilihan. Gejala versi lama: failover yang berhasil tetapi lebih cepat dari seharusnya, dengan risiko split brain pada kondisi jaringan yang tidak bersahabat.

Perbaikan kedua menyentuh pemulihan data. HDEL, HGETDEL, HPERSIST, dan HEXPIRE tidak lagi mempropagasikan field yang mereka anggap sudah kedaluwarsa, sehingga replika dan proses reload AOF tidak menyimpang dari primary. Ditambah perbaikan COPY yang kini menyertakan field kedaluwarsa belum dibersihkan, hasilnya adalah replika yang lebih dekat ke kondisi primary setelah operasi hash bercampur ekspirasi.

Selain itu, valkey-check-aof sekarang mengenali berkas dasar RDB dengan tanda tangan VALKEY, tidak lagi melaporkan AOF multipart yang sah sebagai tidak valid. Bagi tim yang rutin memverifikasi AOF sebelum restart, ini menghilangkan satu sumber alarm palsu.

Kesalahan apa yang sering terjadi saat upgrade keamanan seperti ini?

Kesalahan paling umum bukan pada proses upgrade, melainkan pada cara tim menyimpulkan hasilnya. Tiga pola yang berulang:

• Memeriksa versi dari paket yang terpasang, bukan dari proses yang berjalan. Setelah restart tertunda, paket baru sudah ada tetapi memori masih menjalankan biner lama.
• Menganggap semua node sudah naik karena dasbor menampilkan satu versi. Pada cluster, agregat menyembunyikan node yang tertinggal.
• Melewati uji jalur tracking setelah upgrade, lalu menyalahkan aplikasi ketika pola baca berubah.

Pola keempat lebih halus: menganggap patch keamanan selesai setelah naik versi. Padahal kalau celahnya mensyaratkan kredensial sah, meninjau ulang daftar pemegang kredensial dan cakupan ACL sama pentingnya dengan upgrade itu sendiri. Rilis ini juga memperbaiki crash saat memuat berkas ACL yang berisi selector dengan tanda kurung tidak berpasangan, yang menandakan berkas ACL memang jalur yang perlu diperiksa, bukan sekadar diandalkan.

Bagaimana menakar apakah risiko celah ini nyata di instalasimu?

Ajukan empat pertanyaan. Apakah Valkey menerima koneksi dari jaringan selain localhost dan jaringan internal aplikasi? Apakah Pub/Sub dipakai di mode cluster? Apakah ada lebih dari satu tim atau layanan yang memegang kredensial? Dan apakah ada jalur yang memungkinkan klien mengirim pesan Pub/Sub dengan ukuran sembarang?

Kalau semua jawabannya tidak, risikonya rendah tetapi bukan nol, karena celah ini tetap terbuka bagi siapa pun yang berhasil mendapat kredensial. Kalau satu saja jawabannya ya, perlakukan sebagai prioritas: jadwalkan upgrade dalam hitungan hari, bukan minggu, dan tinjau ACL bersamaan dengan itu.

Kesimpulannya, 9.1.3 adalah rilis pemeliharaan yang isinya justru lebih banyak pada konsistensi data daripada pada celahnya sendiri. Naik versi, uji tiga jalur yang berubah, tinjau kredensial, lalu tutup pekerjaan dengan memastikan semua node benar-benar melaporkan versi baru.

FAQ

Apakah Valkey 9.1.3 kompatibel dengan klien Redis biasa?

Protokolnya tetap sama, jadi klien yang bekerja dengan versi 9.1 sebelumnya umumnya langsung berjalan. Yang berubah adalah perilaku notifikasi pada stream command, jadi uji jalur tracking di aplikasi sebelum menyatakan kompatibel penuh.

Perlukah failover kalau hanya punya satu node?

Dengan satu node, upgrade berarti restart dan itu memutus layanan selama proses. Siapkan jendela pemeliharaan, ambil snapshot lebih dulu, dan pastikan klien punya mekanisme reconnect sebelum menjadwalkannya.

Apakah celah ini bisa dipicu tanpa autentikasi?

Catatan rilis menyebut klien terautentikasi sebagai syarat. Artinya kredensial tetap menjadi garis pertahanan pertama, dan itu alasan tambahan untuk meninjau ulang siapa saja yang punya akses Pub/Sub di klaster.

Bagaimana kalau saya masih memakai Redis versi lama?

Artikel ini tidak menilai versi Redis. Yang bisa dipastikan, perbaikan serupa hanya sampai ke jalur rilis Valkey. Kalau kamu mempertimbangkan pindah, uji kompatibilitas modul dan perilaku replikasi lebih dulu, karena keduanya area yang paling berbeda.

Sumber utama tulisan ini adalah catatan rilis Valkey 9.1.3, advisory GHSA-f4q9-j22m-xqq9, dan halaman unduhan resmi Valkey.