MongoDB Sunucularında Kritik Kimlik Doğrulama Öncesi Güvenlik Açığı (CVE-2026-118383) Tespit Edildi

MongoDB Sunucularında Kritik Kimlik Doğrulama Öncesi Güvenlik Açığı (CVE-2026-118383) Tespit Edildi

MongoDB sunucusunda bulunan kritik bir güvenlik açığı, kimlik doğrulaması yapılmamış bir saldırganın iki istek göndererek veritabanı sunucusunda çökme tetiklemesine olanak tanıyor. Bu çökme, yalnızca sunucunun bazı güncel değişikliklerden yoksun kalması durumunda ana sunucu olarak seçilmesi halinde meydana geliyor.

Veritabanını geliştiren MongoDB şirketi, bu hafta başında düzeltilmiş sürümleri yayınladı.

Etkilenen sunucular, aynı verinin kopyalarını tutan bir grup MongoDB sunucusu olan replika setlerinin üyeleridir. Birincil üye, ana sunucu olarak görev yapar ve tüm yeni yazma işlemlerini yönetirken, diğer üyeler bunları çoğaltır. Birincil üye kullanılamaz hale gelirse, diğer üyeler yeni bir birincil üye seçmek için bir seçim yapar.

Datadog Security Labs araştırmacıları, bu çökme durumunu laboratuvar ortamında yeniden oluşturdu ve bulgularını dün yayınladı. Güvenlik açığı bulunan sürümlerde, kimlik doğrulama açık olsa bile bu iki isteği durdurmak mümkün olmuyor. Araştırmacılar, bir saldırganın hedef alınan üyenin geride kalmasını veya bir seçim kazanmasını sağlayamayacağını ya da bunların ne zaman gerçekleştiğini göremeyeceğini belirtti.

CVE-2026-118383 olarak takip edilen güvenlik açığı, bir ‘kullanım sonrası serbest bırakma’ (use-after-free) hatasıdır: sunucu, daha önce serbest bıraktığı belleği kullanmaya devam eder. MongoDB, bu açığı CVSS 4.0 şiddet ölçeğinde 10 üzerinden 9.5 olarak derecelendirdi. Şirket, açığı kendisinin bulduğunu ve “bu güvenlik açığından yararlanmaya yönelik herhangi bir girişimden haberdar olmadığını” ifade etti.

Etkilenen üyeler arasında parçalanmış kümelerin (sharded clusters) shard ve yapılandırma sunucusu üyeleri bulunmaktadır. Herhangi bir replika setinin dışında tek başına çalışan bir mongod sunucusu etkilenmemektedir.

Etkilenen her dal için düzeltilmiş bir sürüm bulunmaktadır ve bunlar aşağıda ve CVE kaydında listelenmiştir. Bir daldaki her önceki sürüm, dalın ilk sürümüne kadar etkilenmektedir.

MongoDB, güvenlik duyurusunda, MongoDB Atlas kümelerinin bakım sırasında otomatik olarak düzeltilmiş sürümleri aldığını belirtti. Bakımı erteleyen müşterilerin yükseltmeyi mümkün olan en kısa sürede uygulamaları gerekmektedir.

Kendi kendine yönetilen dağıtımlar, her replika seti üyesinde düzeltilmiş sürüme ihtiyaç duyar. Yükseltme sonrasında, kapsayıcılardaki ve bakım sırasında çevrimdışı olanlar da dahil olmak üzere her üyenin hangi sürümü çalıştırdığını kontrol edin.

8.2 dalı, listelenen etkilenen sürümler arasında yer almamaktadır ve en yeni sürümü 8.2.12’dir. Ancak GitHub’da yayınlanan bir proof of concept (PoC), 8.2.12’nin laboratuvar testinde, yalnızca test amaçlı bir ayar kullanılarak hatayı hala gösterdiğini bildirmektedir.

Şirketin yaşam döngüsü programına göre, 8.2 dalı 31 Temmuz’da kullanım ömrünü tamamlamıştır. Bu tarihten sonra bir sürüm, güvenlik düzeltmeleri de dahil olmak üzere artık düzeltme almamaktadır.

Bir üye yükseltilene kadar, araştırmacılar veritabanına ağ erişimini yalnızca ihtiyacı olan sistemlerle sınırlamayı önermektedir. Bu, iki isteği gönderebilecek kişi sayısını sınırlar ancak hatayı düzeltmez.

Datadog araştırmacılarının teknik analizine göre, bir seçimi kazanan üye, yeni yazma işlemlerini kabul etmeden önce kaçırdığı yazma işlemlerini uygulayarak önce kendini günceller. Hata, bu yakalama adımının (catch-up step) sonunda çalışan temizleme işlemindedir.

İki istek, bir readConcern.afterOpTime değeri taşıyan ping komutlarıdır. Her biri sunucudan çoğaltmanın belirli bir noktaya ulaşmasını beklemeyi ister ve sunucu bunun için bir bekleyen bildirim (waiter) kaydeder.

Bekleyenleri yerleştirmek sunucuyu çökertmez. Bunlar süresi dolmaz ve üye yeniden başlayana, geri dönene veya birincil konumdan ayrılana kadar yerinde kalırlar.

Çökme, istekleri alan üyenin, başka bir üyenin gerisinde olmasına rağmen daha sonraki bir seçimi kazanmasını gerektirir. Yakalama işlemi sona erdiğinde, temizleme işlemi iki kez çalışır, zaten serbest bırakılmış belleği yeniden kullanır ve yeni birincil sunucu herhangi bir yazma işlemini kabul etmeden önce çöker. Bu koşullar karşılandığında, çökme bir zamanlama yarışını kazanmaya bağlı değildir, araştırmacılar belirtti.

Laboratuvarda araştırmacılar, yönetici erişimi kullanarak mongod süreçlerini duraklatıp durdurarak üyenin geride kalmasına ve bir failover’ı zorlamasına neden oldular. Yalnızca iki istek, kimlik bilgileri olmayan bir istemciden geldi ve bu istemci veritabanına yazma yapamadı.

8.0.34 sürümünde, üye bir segmentasyon hatasıyla çöktü ve laboratuvar kümesini birincil sunucusuz bıraktı. Başka bir dağıtım yeni bir birincil sunucu seçebilir ve çalışmaya devam edebilir.

Düzeltilmiş 8.0.37 sürümünde, sunucu her iki isteği de yetkisiz olarak hemen reddetti ve üye çalışmaya devam etti. Düzeltmenin bir kısmı, yalnızca sistem kullanıcılarının readConcern.afterOpTime kullanmasına izin veriyor.

MongoDB, güvenlik açığının belirli koşullar altında sunucu sürecinde rastgele kod yürütülmesine de yol açabileceğini belirtiyor. Ancak laboratuvarda, “kod yürütmeyi başaramadık” diyen araştırmacılar, sonuçlarının saldırının diğer kurulumlarda ne sıklıkla işe yarayacağını göstermediğini de ekledi.

Proof-of-concept kodu, yazarına göre hatayı bir laboratuvar replika setinde yeniden üretmektedir. Güvenilir modu, uzaktan bir saldırganın etkinleştiremeyeceği yalnızca test amaçlı bir ayar gerektirir. Belirtilen etkisi, kod yürütme iddiası olmaksızın bir çökme veya bellek bozulmasıdır.

Araştırmacılar, düzeltmenin ikinci kısmının, bekleyenler zaten yerinde olsa bile temizleme işleminin iki kez çalışmasını engellediğini belirtti. Bu kısmı kendileri test etmediler.

Kimlik doğrulama kapalıyken çalışan proof-of-concept laboratuvar testinde, düzeltilmiş 8.0.37, yerleştirilen bekleyenleri kabul etti ancak temizleme işlemini yalnızca bir kez çalıştırdı.

Yerleştirme veya çökme belirtilerini aramak için, araştırmacıların güvenlik açığı bulunan çalıştırmalarından elde edilen şu işaretleri sunucunun yapılandırılmış günlüklerinde kontrol edin:

• Günlük olayı: MaxTimeMSExpired ile sona eren, kimlik doğrulaması yapılmamış, readConcern.afterOpTime taşıyan bir ping için COMMAND “Slow query” girişi (ID 51803).
• Günlük olayı: bir üyenin birincil yakalama durumuna girmesi (ID 21359), ardından tek bir geçişte iki kez çıkması (ID 21363).
• Günlük olayı: bu çıkışlardan sonra CatchupState::abort_inlock() içeren ölümcül bir sinyal veya geri izleme.

Normal bir seçim veya tek bir yakalama çıkışı bu hatayı işaret etmez. İstekler failover’dan önce de gelebileceğinden, aynı üyeden daha önceki günlükleri de kontrol edin.

İstek alanlarının günlüğe kaydedilip kaydedilmediği günlük ayarlarıma bağlıdır ve attr.remote alanı istemcinin gerçek IP’si yerine bir geri döngü adresi gösterebilir.