MongoDB'deki kritik açık yetkisiz isteklerle sistem çökmesine yol açıyor

MongoDB, bir yedekleme üyesinin en yeni ana sunucu olarak seçilip güncel olmayan verilerle çalışmaya başladığında sistemin çökmesine neden olan CVE-2026-118383 olarak adlandırılan ciddi bir güvenlik açığını yamaladı. Şirket, bu sorunun bu hafta başında yayımlanan güncellere dahil edildiğini duyurdu. Açığın, MongoDB güvenlik laboratuvarları ekibi tarafından tespit edildiği belirtildi.

Veri tablosundaki elemanlar nasıl etkileniyor?​

Yöneticiler, veri tablosundaki yedekleme üyelerinin veya şarflı kümelerin bir parçası olan sunucuların bu etkilenebileceğini belirtti. Tek başına çalışan bir sunucu etkilenmiyor. Şirket, tüm sunucuların etkilenen dallarıyla ilgili olarak eski sürümlerdeki tüm kullanımlarının etkilenebileceğini, ancak her yeni sürümün bu sorunu düzelttiğini söyledi. Atlas kullanıcıları, yamaların bakım penceresinde otomatik olarak alacağı sürümlerini kullandı, ancak bu bakımı erteleyen kullanıcıların yamanın en kısa sürede uygulamaları gerektiği konusunda uyardı.

Saldırının çalışma mekanizması nedir?​

Açığın, kullanılmış bir bellek alanını kullanma hatasından kaynaklandığı açıklandı. Yöneticiler, veri tablosundaki elemanlara yavaşlama yaptırıp yedeğin ana sunucu olarak seçilmesini bekleyerek istenmeyen bir çökmenin nasıl tetiklenbileceğini gösteren bir laboratuvar testi sundular. Ancak, bir elemanın yavaşlamasını veya yedekleme sürecini kazanmasını doğrudan başlatamadığı, bu olayların gerçekleşip gerçekleşmediğini de göremediği vurgulandı.
Yöneticiler, bu hatanın bir eleman daha yeni bir elemanın gerisindeyken bir seçim kazandığında, yakalama adımının bitiminde çalışan temizlik işleminin hatalı şekilde ikinci kez çalışmasından kaynaklandığını belirtti. Bu durum, elemanın yeni talepleri kabul etmeden önce çökmesine neden oluyor.

Yeniden yazım nasıl yapıldı ve kullanıcılar ne görmeli?​

Yapılan düzeltme, iki ana parçadan oluşuyor. Birincisi, veri tablosu okuma endişesi ayarını yalnızca sistem kullanıcıları için kullanıma sunuyor. İkincisi, temizlik işleminin elemanlar zaten varken iki kez çalışmasını engelliyor. Bu, yöneticilerin elemanların kurulumunu veya çökmesini bulmak için veri tablosu loglarında kontrol etmesi gereken belirtiler olduğunu açıklıyor.
Yöneticiler, veri tablosu loglarında yapılandırılmış olayları aramanın, özellikle belirli komut girdilerinin veya eleman geçişlerinin birden fazla çıkışın olduğunu gösteren kayıtların bu sorunu bulmaya yardımcı olacağını belirtiyor. Bir elemanın bu açığa sahip sürümden yeni sürüme yükseltilmesinin ardından, bu olayların görülmesi durumunda, o elemanla ilgili olarak veri tablosu yapılandırması kontrol edilmeli.

Sıkça Sorulan Sorular​

CVE-2026-118383 açık neyi ifade ediyor?​

CVE-2026-118383, MongoDB yedekleme seti üyelerinin, geride kalan bir elemanın ana sunucu olarak seçilmesi durumunda veri tablosu sunucunun çökmesine neden olabileceği kritik bir güvenlik açığıdır. Bu, bir elemanın, ana sunucu ile senkronize olmadan önce güncel olmayan verilerle çalışması durumundan kaynaklanmaktadır.

Yeniden yazma, yamadan sonra bile veri tablosu loglarında arama yapılmasını gerektiriyor mu?​

Evet, yamadan sonra bile veri tablosu loglarında belirli bir olay dizisini aramak, bir elemanın bu açığa sahipken bu durumun yaşayıp yaşamadığını belirlemek için öneriliyor. Bu, bir elemanın kurulum veya çökme gibi belirli olayların loglarında birden fazla kez görülüp görülmediğini kontrol etmeyi içeriyor.

Atlas ve kendi kendine yönetilen dağıtımlar arasındaki fark nedir?​

Atlas dağıtımlarında, yamalar otomatik olarak bakım penceresinde uygulanırken, kendi kendine yönetilen dağıtımlarda her veri tablosu üyesinin yamalanmış sürüm çalıştırması ve bu üyelerin sürüm kontrolü edilmesi gerekiyor. Bu, konteyner içindeki veya bakımda çevrimdışı olan üyeler dahil olmak üzere, tüm yedekleme seti üyelerini kapsıyor.

Bu açık, veri tablosuna yazma yeteneği gerektiriyor mu?​

Hayır, bu açık veri tablosuna yazma yeteneği gerektirmez. İstenen saldırı, yetkisiz, yani kimlik bilgileri olmayan, bir istemci tarafından gerçekleştirilebilir ve bu istemcinin veri tablosuna yazma yetkisi yok. Saldırı, belirli komutları göndererek ve yedekleme elemanının ana sunucu olarak seçilip güncellenmemiş bir durumla çalışmaya başlamasını bekleyerek yapılır.

Şirket, bu açığın kötüye kullanım girişimiyle ilgili bilgi sahibi mı?​

MongoDB, bu açığın kötüye kullanım girişimiyle ilgili herhangi bir şeyden haberdar olmadığını belirtti. Şirket, güvenlik açıklarının elemanların veri tablosu loglarında belirli bir olay dizisini aramaları gerektiğini, ancak bu olayların bu açığa bağlı olduğunu doğrulamadığını vurguluyor.