CVE-2026-118383: Celah Kritis MongoDB Pra-Autentikasi Bisa Lumpuhkan Server saat Failover

Celah kritis pada MongoDB Server memungkinkan penyerang tanpa autentikasi mengirim dua permintaan yang memicu crash. Serangan hanya berhasil jika server yang sama kemudian terpilih sebagai primary saat masih tertinggal data. MongoDB telah merilis versi perbaikan.

Apa Itu CVE-2026-118383 dan Mengapa Berbahaya?

CVE-2026-118383 adalah kerentanan use-after-free pada MongoDB Server. Dalam kondisi tertentu, server menggunakan memori yang sudah dibebaskan, sehingga bisa berujung pada crash. MongoDB memberi skor 9,5 dari 10 pada skala CVSS 4.0, menempatkannya di kategori kritis.

Yang membuat celah ini menonjol adalah sifatnya yang pra-autentikasi. Mengaktifkan autentikasi pada versi rentan tidak menghalangi dua permintaan berbahaya tersebut. Penyerang tidak perlu memiliki kredensial untuk mengirimkannya.

Peneliti dari Datadog Security Labs mereproduksi crash di laboratorium dan mempublikasikan temuan mereka. Mereka menjelaskan bahwa penyerang tidak dapat membuat anggota yang ditargetkan tertinggal atau memenangkan pemilihan, juga tidak dapat melihat kapan peristiwa itu terjadi.

MongoDB menyatakan menemukan celah ini sendiri dan "tidak mengetahui adanya upaya untuk memanfaatkan kerentanan ini." Perusahaan merilis versi perbaikan awal pekan ini.

Kronologi Penemuan dan Publikasi Temuan

MongoDB lebih dulu merilis pembaruan keamanan. Beberapa hari kemudian, Datadog Security Labs mempublikasikan analisis teknis dan bukti konsep (proof of concept) di GitHub. Laboratorium mereka menguji versi 8.0.34 yang rentan dan versi 8.0.37 yang telah diperbaiki.

Dalam uji lab, peneliti sengaja membuat anggota replica set tertinggal dan memaksa failover dengan menjeda serta menghentikan proses mongod menggunakan akses admin. Hanya dua permintaan yang berasal dari klien tanpa kredensial, dan klien itu tidak dapat menulis ke basis data.

Pada versi 8.0.34, anggota tersebut mengalami crash dengan segmentation fault, meninggalkan klaster lab tanpa primary. Di deployment lain, sistem mungkin memilih primary baru dan tetap berjalan.

Pada versi 8.0.37, server menolak kedua permintaan sebagai tidak berwenang dan anggota tetap berjalan. Salah satu bagian perbaikan membatasi penggunaan readConcern.afterOpTime hanya untuk pengguna sistem.

Pihak yang Terlibat dan Pernyataan Resmi

MongoDB sebagai pengembang basis data merilis perbaikan dan pengumuman keamanan. Perusahaan menegaskan bahwa klaster MongoDB Atlas menerima versi perbaikan secara otomatis selama pemeliharaan. Pelanggan yang menunda pemeliharaan diminta segera menerapkan peningkatan.

Datadog Security Labs menjadi pihak yang mempublikasikan analisis teknis. Mereka menulis bahwa "kami tidak mencapai eksekusi kode" dalam lab, meskipun MongoDB menyebut celah ini berpotensi menyebabkan eksekusi kode arbitrer dalam kondisi tertentu.

Penulis proof of concept di GitHub menyatakan kode tersebut mereproduksi bug pada replica set lab. Mode andalannya memerlukan pengaturan khusus pengujian yang tidak dapat diaktifkan oleh penyerang jarak jauh. Dampak yang diklaim adalah crash atau korupsi memori, tanpa klaim eksekusi kode.

Hingga berita ini ditulis, belum ada laporan eksploitasi di dunia nyata. Namun publikasi bukti konsep meningkatkan risiko karena kode tersedia untuk umum.

Dampak pada Replica Set dan Klaster Sharded

Server yang terpengaruh adalah anggota replica set, yaitu kelompok server MongoDB yang menyimpan salinan data yang sama. Satu anggota menjadi primary dan menangani semua penulisan baru, sementara anggota lain mereplikasi data. Jika primary tidak tersedia, anggota lain mengadakan pemilihan untuk memilih primary baru.

Anggota yang terkena termasuk shard dan config server pada klaster sharded. Standalone mongod, yaitu server tunggal di luar replica set, tidak terpengaruh.

Setiap cabang versi yang terpengaruh memiliki rilis perbaikan. Semua versi sebelumnya dalam cabang tersebut rentan, sejak rilis pertama cabang. Cabang 8.2 tidak termasuk dalam daftar versi yang terpengaruh, dan rilis terbarunya adalah 8.2.12. Namun proof of concept di GitHub melaporkan bahwa 8.2.12 masih menunjukkan bug dalam uji lab menggunakan pengaturan khusus pengujian.

Cabang 8.2 mencapai akhir masa pakai (end of life) pada 31 Juli 2026. Setelah tanggal itu, versi tersebut tidak lagi menerima perbaikan, termasuk perbaikan keamanan.

Langkah Mitigasi dan Pemeriksaan Log

Hingga anggota dapat ditingkatkan, peneliti menyarankan membatasi akses jaringan ke basis data hanya untuk sistem yang memerlukannya. Langkah ini membatasi siapa yang dapat mengirim dua permintaan tersebut, tetapi tidak memperbaiki celah.

Deployment yang dikelola sendiri perlu menerapkan rilis perbaikan pada setiap anggota replica set. Setelah peningkatan, periksa versi yang dijalankan setiap anggota, termasuk anggota dalam kontainer dan yang offline selama pemeliharaan.

Untuk mendeteksi upaya penanaman waiter atau crash, periksa log terstruktur server untuk tanda-tanda berikut dari uji lab peneliti:

• Entri COMMAND "Slow query" (ID 51803) untuk ping tanpa autentikasi yang membawa readConcern.afterOpTime dan berakhir dengan MaxTimeMSExpired.
• Anggota memasuki primary catch-up (ID 21359), lalu keluar dua kali (ID 21363) dalam satu transisi.
• Sinyal fatal atau backtrace yang melibatkan CatchupState::abort_inlock() setelah keluar tersebut.

Pemilihan normal atau satu kali keluar catch-up tidak menunjuk pada celah ini. Permintaan juga bisa datang sebelum failover, jadi periksa log sebelumnya dari anggota yang sama. Apakah field permintaan dicatat bergantung pada pengaturan logging, dan field attr.remote mungkin menampilkan alamat loopback alih-alih IP asli klien.

Analisis Redaksi

CVE-2026-118383 menunjukkan bahwa fitur yang tampak tidak berbahaya seperti ping dengan readConcern.afterOpTime bisa menjadi vektor serangan jika penanganan memori tidak hati-hati. Skor 9,5 pantas diberikan karena penyerang tidak perlu autentikasi, dan dampaknya adalah hilangnya primary pada replica set. Dalam sistem produksi, kehilangan primary dapat memicu downtime dan mengganggu ketersediaan layanan.

Yang menarik, MongoDB menyebut potensi eksekusi kode arbitrer, tetapi peneliti Datadog tidak mencapainya di lab. Perbedaan ini wajar dalam riset keamanan: kondisi lab tidak selalu mencerminkan kompleksitas deployment nyata. Namun klaim eksekusi kode tetap harus diwaspadai, terutama karena proof of concept telah tersedia untuk umum. Pengguna yang menunda patch mengambil risiko yang tidak perlu.

Kasus ini juga menyoroti pentingnya siklus hidup versi. Cabang 8.2 yang telah end of life masih dilaporkan rentan dalam uji lab, meskipun tidak termasuk daftar resmi. Organisasi yang masih menjalankan versi usang harus mempertimbangkan migrasi ke cabang yang didukung. Membatasi akses jaringan adalah langkah sementara yang baik, tetapi bukan solusi. Patch adalah satu-satunya jalan keluar.

Sumber: github.com