Metabase CVE-2026-72898: Aktif İstismar Edilen Kritik SQL Enjeksiyonu İçin Acil Müdahale
Açığın kapsamı ve neden acil olduğu
Metabase güvenlik duyurusuna göre CVE-2026-72898, kimlik doğrulaması gerektirmeyen bir uç nokta üzerinden Metabase uygulama veritabanına keyfî SQL sorgusu enjekte edilmesine imkân verebiliyor. Üretici, saldırganın bu yolla Metabase örneğinde yönetici erişimi elde edebileceğini ve açığın aktif biçimde istismar edildiğini doğruluyor. GitHub güvenlik kaydı açığı kritik, CVSS 10.0 olarak değerlendiriyor.
Yönetici erişimi yalnızca gösterge panolarını değiştirme riski anlamına gelmiyor. Metabase kaydına göre saldırgan uygulama yapılandırmasını değiştirebilir, bağlı veritabanları için saklanan kimlik bilgilerini ele geçirebilir, bu bağlantıların erişebildiği verileri okuyabilir ve dışa aktarabilir. Bu nedenle olay hem uygulama sunucusunu hem de arkasındaki veri ambarlarını kapsayan bir güvenlik problemi olarak ele alınmalıdır.
Etkilenen ve düzeltilmiş sürümler
Güvenlik kaydı x.58, x.59, x.60, x.61, x.62 ve x.63 ana sürüm kollarındaki çeşitli eski sürümlerin etkilendiğini belirtiyor. Üreticinin yayımladığı düzeltilmiş sürümler x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 ve x.63.5 olarak listeleniyor. Kullanılan ana sürüme karşılık gelen yama veya daha yeni desteklenen sürüm kurulmalıdır.
Sadece konteyner etiketinin “latest” olarak tanımlanması güncellemenin kurulduğunu kanıtlamaz. Çalışan pod, container veya JAR dosyasının gerçek sürümü uygulama içinden ve dağıtım sistemi üzerinden doğrulanmalıdır. Eski imajların yeniden başlatma sırasında geri dönmesini önlemek için dağıtım tanımları, imaj özetleri ve özel registry önbellekleri de kontrol edilmelidir.
CISA KEV kaydı ne söylüyor?
CISA, CVE-2026-72898’i 11 Ağustos 2026 tarihinde Bilinen İstismar Edilen Güvenlik Açıkları kataloğuna ekledi. Katalog, açığın sahada istismar edildiğine dair kanıt bulunduğunu ve risk temelli önceliklendirme yapılması gerektiğini gösteriyor. CISA kaydında bilinen fidye yazılımı kampanyası kullanımı “bilinmiyor” olarak işaretli; bu ifade aktif istismar bilgisini geçersiz kılmaz.
Federal kurumlar için verilen son tarih 14 Ağustos olsa da özel kuruluşların bu tarihi bekleme eşiği gibi yorumlamaması gerekir. İnternete açık, iş verilerine bağlı veya yönetici hesapları barındıran Metabase örnekleri en yüksek öncelikle ele alınmalıdır. Yama, maruziyet ve olası ihlal araştırması aynı anda yürütülmelidir.
Hemen uygulanacak koruma adımları
Metabase mümkün olan en kısa sürede uygun düzeltme sürümüne yükseltilmelidir. Üretici, hemen güncelleme yapılamıyorsa geçici önlem olarak /api/session/reset_password uç noktasının engellenmesini öneriyor. Bu kural ters proxy, web uygulama güvenlik duvarı veya yük dengeleyicide uygulanabilir; ancak geçici engelleme kalıcı yamanın yerini tutmaz.
- İnternete açık tüm Metabase alan adlarını ve IP adreslerini envantere alın.
- Çalışan gerçek sürümü belirleyip düzeltilmiş sürümle karşılaştırın.
- Yükseltme tamamlanana kadar önerilen uç noktayı dış erişime kapatın.
- Uygulama ve veritabanı yedeklerinin geri yüklenebilirliğini doğrulayın.
- Yükseltme sonrası oturumları, anahtarları ve hesapları yeniden inceleyin.
Erişim kuralı yalnızca ana alan adına değil, doğrudan IP erişimine, alternatif host adlarına ve unutulmuş test örneklerine de uygulanmalıdır. Bulut güvenlik grupları ile ters proxy yapılandırması birlikte incelenmelidir. Yama öncesinde alınan yedekler olay incelemesi için saklanmalı, fakat şüpheli sistemin eski hâli üretime geri döndürülmemelidir.
Güncellemeden önce uygulama veritabanının tutarlı bir yedeği ve ilgili günlükler korunmalıdır. Yedek dosyası erişimi sınırlandırılmalı, bütünlük özeti kaydedilmeli ve olay incelemesi tamamlanana kadar normal saklama politikasından ayrı tutulmalıdır. Bu hazırlık hem geri dönüş olanağı sağlar hem de şüpheli değişikliklerin sonradan karşılaştırılmasına yardımcı olur.
Yama sonrasında yapılacak olay incelemesi
Üretici, uç nokta herkese açıksa güncellemeden sonra tüm aktif kullanıcı oturumlarının iptal edilmesini öneriyor. Metabase uygulama veritabanındaki core_session tablosunda bulunan oturum kayıtları kontrollü biçimde temizlenmeli; işlem öncesinde desteklenen yöntem ve geri dönüş planı doğrulanmalıdır. Ardından tanınmayan API anahtarları silinmeli ve yönetici hesaplarında beklenmedik değişiklikler aranmalıdır.
Bağlı veritabanlarının kimlik bilgileri, yalnızca Metabase parolası değiştirilerek korunmuş olmaz. Uygulamanın erişebildiği veri ambarı ve veri tabanı hesaplarının parolaları veya anahtarları döndürülmeli, yetkileri en az ayrıcalık ilkesine göre daraltılmalıdır. Veri ambarı günlükleri, Metabase etkinlik kayıtları ve sorgu geçmişi olağandışı okuma, dışa aktarma ve yönetim işlemleri açısından incelenmelidir.
Doğrulama ve kalıcı sertleştirme
Yükseltme sonrasında uygulama sağlık kontrolleri, gösterge panoları, zamanlanmış sorgular ve veri kaynağı bağlantıları test edilmelidir. Ardından dış ağdan eski uç noktanın erişim davranışı doğrulanmalı ve çalışan sürüm yeniden okunmalıdır. Yalnızca paketin indirilmesi veya container’ın yeniden başlaması başarı sayılmamalı; tüm örneklerin düzeltilmiş sürümde olduğu kanıtlanmalıdır.
- Varlık envanterini çalışan sürüm ve internet maruziyetiyle eşleştirin.
- Her ana sürüm kolunu üreticinin düzeltilmiş sürümüne yükseltin.
- Tüm oturumları iptal edip tanınmayan API anahtarlarını kaldırın.
- Yönetici hesaplarını ve bağlı veritabanı kimliklerini döndürün.
- Uygulama, proxy ve veri ambarı günlüklerini zaman çizelgesiyle inceleyin.
- Sonuçları varlık bazında belgeleyip açık istisnalara sahip atayın.
Kalıcı koruma için Metabase yönetim arayüzü doğrudan internete açılmamalı, SSO ve çok faktörlü kimlik doğrulama uygulanmalı, bağlı veri tabanı hesaplarına yalnızca gerekli okuma yetkileri verilmelidir. Güvenlik güncellemeleri için sürüm takibi otomatikleştirilmeli ve yeni imajlar önce kısa bir pilot testten geçirilerek hızlı biçimde üretime alınmalıdır.