MongoDB dapat mulai tanpa otorisasi: tiga cabang perlu patch

Peringatan CSA Singapura pada 15 September 2026 menyebut kesalahan validasi konfigurasi MongoDB Server dapat membuat subsistem otorisasi tetap nonaktif saat startup. Dalam kondisi itu, penyerang tanpa autentikasi yang memiliki akses jaringan dapat menjalankan operasi administratif dan memengaruhi kerahasiaan, integritas, serta ketersediaan data.

Kerentanan tersebut tercatat sebagai CVE-2026-82067. Untuk tiga cabang yang dinyatakan terdampak, catatan CVE yang diterbitkan MongoDB sebagai CNA menetapkan rilis perbaikan minimum 7.0.41, 8.0.30, dan 8.3.9; versi yang lebih lama dalam masing-masing rentang harus diperbarui.

Kesalahan kapitalisasi dapat mengubah hasil startup

Cacat berada pada penanganan huruf besar-kecil oleh komponen validasi konfigurasi. Jika kondisi rentan terpenuhi, subsistem otorisasi dapat bertahan pada keadaan bawaan nonaktif ketika server mulai. Akibatnya, keberadaan opsi kontrol akses dalam templat atau berkas konfigurasi belum membuktikan bahwa proses yang sedang berjalan benar-benar menegakkannya.

Dampaknya bukan sekadar kegagalan login. Koneksi tanpa kredensial yang berhasil mencapai deployment dalam keadaan tersebut dapat melakukan operasi administratif sewenang-wenang. Karena itu, paparan bergantung pada dua hal yang perlu diperiksa terpisah: apakah startup menghasilkan otorisasi nonaktif dan apakah layanan dapat dijangkau melalui jaringan.

Skor yang terlihat berbeda pada berbagai halaman memakai standar yang berbeda, bukan penilaian terhadap dua masalah terpisah. Catatan keamanan Ubuntu mencantumkan 9,2 atau Critical menurut CVSS 4.0 dan 8,1 atau High menurut CVSS 3.1; keduanya menyatakan serangan berasal dari jaringan, tidak memerlukan hak awal atau interaksi pengguna, dan berdampak tinggi pada kerahasiaan, integritas, serta ketersediaan.

Tiga cabang yang harus dipetakan ke rilis perbaikan

Frasa “tiga versi” pada judul merujuk pada tiga cabang rilis, bukan tiga build tunggal. Pemetaan perlu dilakukan berdasarkan cabang mayor-minor agar nomor perbaikan dari satu cabang tidak keliru diterapkan pada cabang lain.

MongoDB Server 7.0: versi 7.0.0 sampai sebelum 7.0.41 terdampak; gunakan sekurang-kurangnya 7.0.41.
MongoDB Server 8.0: versi 8.0.0 sampai sebelum 8.0.30 terdampak; gunakan sekurang-kurangnya 8.0.30.
MongoDB Server 8.3: versi 8.3.0 sampai sebelum 8.3.9 terdampak; gunakan sekurang-kurangnya 8.3.9.

Inventaris sebaiknya menggunakan versi yang dilaporkan oleh proses aktif, bukan hanya versi paket pada repositori, tag image, atau deklarasi deployment. Cakup seluruh proses mongod dan mongos, anggota replica set, shard, node pemulihan bencana, serta instance sementara yang dibuat oleh otomasi. Cabang yang tidak tercantum tidak boleh langsung dianggap terdampak ataupun aman berdasarkan ekstrapolasi dari tiga rentang tersebut.

Periksa konfigurasi efektif dan paparan jaringan

Untuk setiap instance, cocokkan proses dengan sumber konfigurasi yang benar-benar digunakan saat startup: berkas konfigurasi, argumen layanan, templat, dan nilai yang disuntikkan oleh orkestrator. Periksa ejaan serta kapitalisasi opsi terhadap dokumentasi cabang yang digunakan, lalu cari pesan validasi, opsi yang diabaikan, atau pemakaian nilai bawaan dalam log startup.

Pemeriksaan jaringan harus mengikuti jalur yang benar-benar dapat dilalui koneksi. Tinjau alamat bind, firewall atau security group, penerusan port, load balancer, layanan Kubernetes, peering, VPN, dan akses dari host aplikasi. Pembatasan jaringan dapat memperkecil permukaan serangan selama pemeliharaan, tetapi tidak memperbaiki startup yang meninggalkan otorisasi nonaktif dan tidak menutup risiko dari jaringan internal yang sudah dapat mencapai layanan.

Jika sebuah instance rentan pernah dimulai ulang ketika masih dapat dijangkau, catat rentang waktunya untuk penilaian insiden. Korelasikan waktu startup dengan log koneksi, perubahan pengguna dan peran, operasi administratif, serta perubahan data. Tidak adanya paparan internet langsung bukan bukti bahwa instance tidak dapat dicapai melalui jalur internal.

Patch bertahap tanpa mengabaikan kesehatan klaster

Pembaruan perlu mengikuti topologi deployment. Siapkan cadangan yang dapat dipulihkan dan rencana pengembalian, keluarkan satu anggota dari rotasi bila arsitektur memungkinkan, pasang rilis perbaikan pada cabang yang sama, lalu restart dan validasi sebelum berpindah ke anggota berikutnya. Pada replica set atau sharded cluster, pertahankan kuorum dan rencanakan perpindahan peran primer.

Bekukan perubahan konfigurasi yang tidak berkaitan agar kegagalan lebih mudah ditelusuri.
Batasi sementara jalur jaringan ke klien dan alamat administratif yang diperlukan.
Perbarui anggota non-primer atau kelompok kecil terlebih dahulu.
Tunggu sampai node kembali sehat dan tersinkronisasi sebelum melanjutkan.
Buka kembali jalur jaringan hanya setelah kontrol akses lolos validasi.

Rilis minimum adalah batas perbaikan untuk kerentanan ini, bukan keharusan berhenti tepat pada nomor tersebut. Jika tersedia rilis lebih baru yang kompatibel pada cabang yang sama, tim dapat memilihnya setelah memeriksa perubahan dan persyaratan deployment. Perpindahan cabang mayor-minor sebaiknya dipisahkan dari patch darurat apabila kompatibilitas driver, fitur, dan konfigurasi belum diuji.

Validasi otorisasi setelah setiap restart

Pertama, pastikan proses aktif melaporkan versi yang dituju dan memuat konfigurasi yang semestinya. Periksa log startup, kesehatan node, serta status replikasi sebelum pembaruan diteruskan. Pemeriksaan ini menangkap kegagalan operasional, tetapi belum membuktikan bahwa akses anonim ditolak.

Kedua, uji kontrol akses dari jaringan pengujian yang memang diizinkan. Koneksi tanpa kredensial harus gagal ketika mencoba operasi administratif, sedangkan akun uji yang sah hanya boleh menjalankan tindakan sesuai perannya. Pengujian harus terbatas dan terkontrol; database tidak perlu dibuka ke internet untuk membuktikan penolakan akses anonim.

Perbaikan telah tersedia bagi ketiga cabang yang tercantum. Status akhirnya tetap harus dibuktikan pada setiap deployment: proses menjalankan rilis yang telah diperbaiki, konfigurasi efektif dimuat saat startup, akses tanpa autentikasi ditolak, dan periode startup sebelumnya yang mungkin terpapar telah dinilai.

MongoDB bisa mulai tanpa otorisasi—tiga versi wajib segera diperbarui