MongoDB, kimlik doğrulama yapılmadan gönderilebilen iki istekle tetiklenen ve replica set üyelerinde sunucuyu çökerten kritik açık için düzeltme yayımladı. CVE-2026-118383 olarak izlenen hata, bir üye daha sonra yeni primary seçildiğinde ve hâlâ bazı güncel değişiklikleri almamışken ortaya çıkıyor.
Açık, MongoDB sunucusunun replica set içinde çalıştığı yapılarda görülüyor. Replica set, aynı verinin kopyalarını tutan sunucu grubunu ifade ediyor; bu grupta primary yeni yazıları karşılıyor, diğer üyeler bu yazıları kopyalıyor. Primary kullanılamaz hale gelirse diğer üyeler yeni primary’yi seçmek için oylama yapıyor.
Datadog Security Labs araştırmacıları, hatayı laboratuvarda yeniden üretti ve bulgularını dün yayımladı. MongoDB ise düzeltmeli sürümleri bu haftanın başında kullanıma sundu. Şirket, açığı kendi tespit ettiğini ve “bu güvenlik açığından yararlanmaya yönelik herhangi bir girişimden haberdar olmadığını” söyledi.
İki ping isteğiyle çalışan saldırı zinciri
Datadog’un teknik analizine göre sorun, primary catch-up sürecinin bitişinde çalışan temizlik kodundan kaynaklanıyor. Bir üye primary olduğunda, daha önce kaçırdığı yazıları uygulayarak önce senkronize oluyor, ardından yeni yazıları kabul ediyor. Açık, bu geçişin sonundaki cleanup aşamasında ortaya çıkan use-after-free hatası olarak tanımlanıyor; sunucu, daha önce serbest bıraktığı belleği yeniden kullanıyor.
Araştırmacılar, saldırının iki ping isteğiyle kurulduğunu belirtti. Bu istekler readConcern.afterOpTime değeri taşıyor ve her biri sunucudan belirli bir noktaya kadar replikasyonun ulaşmasını beklemesini istiyor. Sunucu da bunun için bekleyen bir bildirim kaydı oluşturuyor; araştırmacılar bu kayda waiter adını veriyor.
Bu waiter’ların oluşturulması tek başına çökme yaratmıyor. Kayıtlar zaman aşımına uğramıyor ve ilgili üye yeniden başlatılana, rollback yapana ya da primary konumundan düşene kadar yerinde kalıyor. Araştırmacılara göre, zayıf sürümlerde authentication açık olsa bile bu iki istek sunucu tarafından engellenmiyor.
Çökme için, istekleri alan üyenin daha sonra yapılan bir seçimde primary olması gerekiyor. Ancak bu anda üyenin başka bir üyeden geride kalmış olması şart. Catch-up sona erdiğinde cleanup iki kez çalışıyor, daha önce serbest bırakılmış bellek yeniden kullanılıyor ve yeni primary, herhangi bir yazıyı kabul etmeden önce çöküyor. Araştırmacılar, bu koşullar sağlandıktan sonra saldırının ayrı bir zamanlama yarışına bağlı olmadığını söyledi.
Laboratuvar kurulumunda araştırmacılar üyenin geride kalmasını sağladı ve admin erişimi kullanarak mongod süreçlerini duraklatıp durdurup failover’ı kendileri tetikledi. İki istek yalnızca kimlik bilgisi olmayan bir istemciden geldi; bu istemci veritabanına yazı da yazamıyordu.
Version 8.0.34 üzerinde üye segmentation fault ile çöktü ve laboratuvar kümesi primary’siz kaldı. Araştırmacılar, başka bir dağıtımın yeni bir primary seçerek çalışmaya devam edebileceğini de aktardı. MongoDB ise fixed 8.0.37 sürümünde sunucunun iki isteği de hemen unauthorized olarak reddettiğini ve üyenin çalışmayı sürdürdüğünü açıkladı.
Şirketin açıklamasına göre düzeltmenin bir parçası, readConcern.afterOpTime kullanımını yalnızca system user’larla sınırlandırıyor. İkinci parça ise waiter’lar zaten yerindeyken bile cleanup işleminin iki kez çalışmasını engelliyor.
Etkilenen sürümler ve yayımlanan yamalar
MongoDB, etkilenen her dal için düzeltilmiş sürümleri listeledi. 8.0 dalında ilk güvenli sürüm 8.0.37 olarak yer alıyor. Bunun yanında 9.0.7, 8.3.16, 7.0.48, 6.0.30, 5.0.35 ve 4.4.32 sürümleri de düzeltmeyi içeriyor. Her dalda, o serinin ilk sürümüne kadar geri gidilen tüm önceki sürümler etkileniyor.
Şirketin yaşam döngüsü programına göre 8.2 dalı etkilenen sürümler arasında listelenmiyor ve bu dalın en güncel sürümü 8.2.12. Buna karşın GitHub’da yayımlanan bir proof-of-concept, 8.2.12’nin laboratuvar testinde, yalnızca test amaçlı bir ayar kullanıldığında, hatayı hâlâ sergilediğini bildiriyor. Aynı yaşam döngüsü tablosu, 8.2 dalının 31 Temmuz 2026’da ömrünün sona ereceğini gösteriyor; bu tarihten sonra sürümler güvenlik yamaları dahil hiçbir düzeltme almıyor.
MongoDB Atlas kümeleri, bakım sırasında düzeltmeli sürümleri otomatik olarak alıyor. Şirket, bakımı erteleyen müşterilerin yükseltmeyi mümkün olan en kısa sürede uygulaması gerektiğini söylüyor. Kendi yönetilen kurulumlarda ise fixed sürümün replica set’in her üyesine yüklenmesi gerekiyor. Şirket ayrıca, kapsayıcı içindeki üyeler ve bakım sırasında çevrimdışı kalanlar da dahil olmak üzere her üyenin çalıştırdığı sürümün yükseltme sonrasında ayrıca kontrol edilmesini istiyor.
Datadog araştırmacıları, düzeltme gelene kadar veritabanına ağ erişiminin yalnızca buna ihtiyaç duyan sistemlerle sınırlandırılmasını öneriyor. Bu, iki isteği gönderebilecek tarafı daraltıyor ancak açığı kapatmıyor.
MongoDB, bu hatanın bazı koşullarda sunucu işleminde arbitrary code execution ile de sonuçlanabileceğini belirtti. Araştırmacılar ise laboratuvarda code execution elde edemediklerini söyledi. Bulguları, saldırının başka kurulumlarda ne sıklıkla çalışacağını da göstermiyor.
Proof-of-concept kodunun yazarı, kodun laboratuvar replica set’inde bug’ı yeniden ürettiğini aktardı. Reliable modun çalışması için uzaktaki saldırganın açamayacağı test amaçlı bir ayar gerekiyor. Kodun belirttiği etki crash ya da memory corruption ile sınırlı ve code execution iddiası taşımıyor.
Araştırmacılara göre ikinci düzeltme, waiter’lar zaten mevcut olsa bile cleanup’ın iki kez çalışmasını durduruyor. Bu kısmı kendileri test etmedi. Ancak authentication kapalı olan proof-of-concept laboratuvar testinde fixed 8.0.37, yerleştirilen waiter’ları kabul etti ve cleanup işlemini yalnızca bir kez çalıştırdı.
Günlüklerde bu açığı arayanlar için araştırmacıların paylaştığı işaretler üç başlıkta toplanıyor. İlki, kimlik doğrulaması olmayan bir ping isteği için readConcern.afterOpTime taşıyan ve MaxTimeMSExpired ile sonuçlanan COMMAND “Slow query” kaydı. İkincisi, bir üyenin primary catch-up’a girdiğini ve aynı geçiş içinde iki kez çıktığını gösteren ID 21359 ve ID 21363 kayıtları. Üçüncüsü ise bu çıkışların ardından CatchupState::abort_inlock() içeren fatal signal ya da backtrace.
Normal bir seçim ya da tek bir catch-up çıkışı bu açıkla doğrudan eşleşmiyor. İstekler failover’dan önce de gelebileceği için aynı üyeye ait daha eski logların da kontrol edilmesi gerekiyor. İstenen alanların loglara yazılıp yazılmaması loglama ayarlarına bağlı; attr.remote alanı ise istemcinin gerçek IP’si yerine loopback adresi gösterebiliyor.
CVE kaydı: https://nvd.nist.gov/vuln/detail/CVE-2026-118383
Kaynaklar
- cve.org
- mongodb.com
- MongoDB Software Lifecycle Schedules | MongoDB (mongodb.com)
- CVE-2026-118383: Use-after-free vulnerability in MongoDB | Datadog Security Labs (securitylabs.datadoghq.com)