MongoBleed (CVE-2025-14847) olarak adlandırılan, birden fazla MongoDB sürümünü etkileyen ciddi bir güvenlik açığı, halka açık web’de 80.000’den fazla potansiyel güvenlik açığına sahip sunucunun açığa çıkmasıyla birlikte aktif olarak kullanılıyor.
Saldırganların, açığa çıkan bir MongoDB sunucusundan sırları, kimlik bilgilerini ve diğer hassas verileri uzaktan çıkarmak için kusuru nasıl tetikleyebileceğini gösteren genel bir istismar ve buna eşlik eden teknik ayrıntılar mevcuttur.
Güvenlik açığına 8,7 önem derecesi verildi ve 19 Aralık’tan bu yana kendi kendini barındıran örnekler için bir yama mevcut olacak şekilde “kritik bir düzeltme” olarak ele alındı.
Exploit sırları sızdırıyor
MongoBleed güvenlik açığı, MongoDB Sunucusunun kayıpsız veri sıkıştırma için zlib kitaplığı tarafından işlenen ağ paketlerini işleme biçiminden kaynaklanmaktadır.
Ox Security’deki araştırmacılar, sorunun, sıkıştırılmış verilerin uzunluğu yerine MongoDB’nin ağ mesajlarını işlerken ayrılan bellek miktarını döndürmesinden kaynaklandığını açıklıyor.
Bir tehdit aktörü, sıkıştırması açıldığında daha büyük bir boyuta sahip olduğunu iddia eden hatalı biçimlendirilmiş bir mesaj göndererek sunucunun daha büyük bir bellek arabelleği ayırmasına ve hassas bilgiler içeren bellek içi verilerin istemciye sızmasına neden olabilir.
Bu şekilde sızdırılan sırların türü, kimlik bilgileri, API ve/veya bulut anahtarları, oturum belirteçleri, kişisel olarak tanımlanabilir bilgiler (PII), dahili günlükler, yapılandırmalar, yollar ve istemciyle ilgili veriler arasında değişebilir.
Ağ mesajlarının sıkıştırmasının açılması kimlik doğrulama aşamasından önce gerçekleştiği için MongoBleed’den yararlanan bir saldırganın geçerli kimlik bilgilerine ihtiyacı yoktur.
Elastic güvenlik araştırmacısı Joe Desimone tarafından “MongoBleed” olarak adlandırılan bir kavram kanıtı (PoC) olarak yayınlanan genel istismar, hassas bellek verilerini sızdırmak için özel olarak oluşturuldu.
Güvenlik araştırmacısı Kevin Beaumont, PoC istismar kodunun geçerli olduğunu ve “veritabanı şifreleri (düz metindir), AWS gizli anahtarları vb. gibi şeyleri bellekte bulmaya başlamak için yalnızca bir MongoDB örneğinin IP adresini” gerektirdiğini söylüyor.
Kaynak: Kevin Beaumont
İnternete bağlı cihazları keşfetmeye yönelik Censys platformuna göre, 27 Aralık itibarıyla halka açık internette 87.000’den fazla potansiyel olarak savunmasız MongoDB örneği bulunuyordu.
Amerika Birleşik Devletleri’nde yaklaşık 20.000 MongoDB sunucusu gözlemlendi, onu yaklaşık 17.000 ile Çin ve 8.000’in biraz altında olan Almanya izledi.
kaynak: Censys
Kullanım ve tespit
Bulut güvenlik platformu Wiz’den alınan telemetri verileri, görünür sistemlerin %42’sinin “CVE-2025-14847’ye karşı savunmasız bir sürümde en az bir MongoDB örneğine sahip olduğunu” gösterdiğinden, bulut ortamındaki etki de önemli görünüyor.
Wiz araştırmacıları gözlemledikleri örneklerin hem iç kaynakları hem de kamuya açık olanları içerdiğini belirtiyor. Şirket, MongoBleed (CVE-2025-14847) istismarını vahşi doğada gözlemlediğini söylüyor ve kuruluşların yama uygulamasına öncelik vermesini tavsiye ediyor.
Her ne kadar doğrulanmamış olsa da bazı tehdit aktörleri, yakın zamanda Ubisoft’un Ranbow Six Siege çevrimiçi platformuna yönelik bir ihlalde MongoBleed kusurunu kullandıklarını iddia ediyor.
Recon InfoSec kurucu ortağı Eric Capuano, yama uygulamasının MongoBleed sorununa yanıtın yalnızca bir parçası olduğu konusunda uyarıyor ve kuruluşlara uzlaşma işaretlerini de kontrol etmelerini tavsiye ediyor.
Dün yayınlanan bir blog yazısında araştırmacı, “yüzlerce veya binlerce bağlantıya sahip ancak sıfır meta veri olayı içeren bir kaynak IP’si” aramayı içeren bir tespit yöntemini açıklıyor.
Ancak Capuano, tespitin şu anda mevcut olan kavram kanıtlama yararlanma koduna dayandığı ve bir saldırganın bunu sahte istemci meta verilerini içerecek veya yararlanma hızını azaltacak şekilde değiştirebileceği konusunda uyarıyor.
THOR APT Tarayıcısının ve binlerce YARA kuralının yaratıcısı Florian Roth, Capuano’nun araştırmasından yararlanarak MongoDB günlüklerini ayrıştıran ve CVE-2025-14847 güvenlik açığından yararlanma potansiyelini belirleyen bir araç olan MongoBleed Detector’u yarattı.
Güvenli kayıpsız sıkıştırma araçları
MongoDB, on gün önce MongoBleed güvenlik açığını gidererek yöneticilerin güvenli bir sürüme (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 veya 4.4.30) yükseltme yapmalarını güçlü bir öneriyle ele aldı.
Satıcı, MongoDB sürümlerinin büyük bir listesinin MongoBleed’den (CVE-2025-14847) etkilendiği konusunda uyarıyor; bazı eski sürümler 2017’nin sonlarında ve bazılarının ise Kasım 2025’te piyasaya sürüldü:
- MongoDB 8.2.0’dan 8.2.3’e
- MongoDB 8.0.0’dan 8.0.16’ya
- MongoDB 7.0.0’dan 7.0.26’ya
- MongoDB 6.0.0’dan 6.0.26’ya
- MongoDB 5.0.0’dan 5.0.31’e
- MongoDB 4.4.0’dan 4.4.29’a
- Tüm MongoDB Sunucusu v4.2 sürümleri
- Tüm MongoDB Sunucusu v4.0 sürümleri
- Tüm MongoDB Sunucusu v3.6 sürümleri
Tam olarak yönetilen, çoklu bulut veritabanı hizmeti MongoDB Atlas’ın müşterileri yamayı otomatik olarak aldı ve herhangi bir işlem yapmaları gerekmiyor.
MongoDB, güvenlik açığına yönelik herhangi bir geçici çözüm olmadığını söylüyor. Yeni bir sürüme geçmek mümkün değilse satıcı, müşterilerin sunucudaki zlib sıkıştırmasını devre dışı bırakmasını önerir ve bunun nasıl yapılacağına ilişkin talimatlar sağlar.
Kayıpsız veri sıkıştırmaya yönelik güvenli alternatifler arasında sırasıyla Meta ve Google tarafından sağlanan Zstandard (zstd) ve Snappy (eski adıyla Zippy) yer alır.
Bozuk IAM yalnızca bir BT sorunu değildir; etkisi tüm işletmenize yayılır.
Bu pratik kılavuz, geleneksel IAM uygulamalarının neden modern taleplere ayak uydurmakta başarısız olduğunu, “iyi” IAM’nin neye benzediğine dair örnekleri ve ölçeklenebilir bir strateji oluşturmak için basit bir kontrol listesini kapsar.