Bu bölümde
Bu hafta Check Point SmartConsole'daki doğrulanmış aktif istismarı, SharePoint'te yama sonrasında devam edebilen makine anahtarı riskini, Xpoda için doğrulanmış bir düzeltme bulunmadığında alınabilecek geçici koruma ve ürün geçişi kararlarını, Azure DevOps MCP araştırmasındaki dolaylı komut enjeksiyonu riskini sakin ve anlaşılır bir akışla değerlendiriyoruz.
Ses şeffaflığı
Bu bölümdeki ses, yerel Chatterbox Multilingual V3 motorunun M5 tabanlı yapay zekâ sesiyle üretilmiştir. Sabit M5 referansı, sürümlenmiş Türkçe telaffuz katmanı ve sonradan hızlandırma uygulanmayan yerel üretim profili kullanılmıştır.
Kaynaklar
- Check Point — Security Advisory: Active Exploitation of SmartConsole Authentication Bypass (CVE-2026-16232)
- CISA Known Exploited Vulnerabilities — CVE-2026-16232
- CERT-EU — Security Advisory 2026-009
- Microsoft Security Response Center — CVE-2026-50522
- USOM — TR-26-0608: Xpoda No Code Platform
- CVE Record — CVE-2026-2395
- Manifold Security — A Confused Deputy in Azure DevOps MCP
- Microsoft — Azure DevOps MCP repository
Konuşma metni
Giriş ve haftanın gündemiBuradan dinle
Hoş geldiniz, siberlab.dev podcastine.
Bu bölümde, güvenlik ekiplerinin çok sık yaptığı bir varsayımı birlikte sorgulayacağız. Güncelleme yayımlandıysa risk gerçekten bitmiş midir? Bazı olaylarda yama yalnızca başlangıçtır. Çalınmış bir anahtar, dışarıya açık bırakılmış bir yönetim arayüzü ya da gereğinden geniş yetkilerle çalışan bir yapay zekâ ajanı, tehlikeyi yama sonrasında da yaşatabilir.
Gündemimizde birbiriyle bağlantılı dört konu var. Önce Check Point yönetim sunucularındaki aktif istismara, ardından SharePoint olayında yamanın neden tek başına yeterli olmadığına bakacağız; Türkiye’den gelen Xpoda bildirimi, henüz doğrulanmış bir düzeltme yokken nasıl karar verilebileceğini gösterecek. Son bölümdeyse Azure DevOps ve MCP araştırması üzerinden yapay zekâ ajanı güvenliğini konuşacağız.
Check Point yönetim düzleminde aktif istismarBuradan dinle
İlk konumuz, Check Point SmartConsole ürünündeki güvenlik açığı. CVE-2026-16232 olarak izlenen bu açık, güvenlik ürününün kendisinden çok onu yöneten merkezi katmanı hedefliyor. Check Point, açığın gerçek saldırılarda kullanıldığını doğruladı; CISA da kaydı 22 Temmuz’da bilinen ve istismar edilen açıklar kataloğuna ekledi.
Riskli senaryo, yönetim sunucusunun internetten erişilebilir olması ve Trusted Clients adı verilen istemci kısıtının kullanılmamasıyla oluşuyor. Başarılı bir saldırı, uygulama giriş belirtecinin ele geçirilmesinden tam yönetici yetkisine kadar ilerleyebiliyor. Bu yetki de güvenlik politikasını ve sistem yapılandırmasını değiştirmek için kullanılabiliyor.
Kanıtın çizdiği sınırı aşmayalım. Check Point, belirli bir internet erişimi yapılandırmasına sahip az sayıda müşterinin etkilendiğini söylüyor. Smart-1 Cloud müşterilerinin ise korunduğunu belirtiyor. Saldırganın kimliği, toplam etkilenen kurum sayısı ve olayların tam kapsamı açıklanmış değil. Aktif istismar doğrulandı, fakat geniş ve tek bir kampanya henüz kanıtlanmadı.
Savunmada önce üreticinin Jumbo Hotfix adıyla yayımladığı acil düzeltme paketini uygulamak gerekiyor. Bunun hemen ardından yönetim erişimini internetten kaldırmak ya da kesin bir izin listesiyle sınırlamak önemli. Trusted Clients tanımlarını ve kontrol bağlantısı kurallarını yeniden doğrulayın. Yayımlanan IP adreslerinden biriyle eşleşme bulmak güçlü bir inceleme işaretidir, fakat eşleşme bulamamak sistemin temiz olduğunu kanıtlamaz.
İncelemede yönetici oturumlarını, yeni uygulama belirteçlerini ve beklenmeyen politika değişikliklerini aynı zaman çizgisinde ele alın. Bu pencereyi yalnızca yamanın kurulduğu saate bağlamayın. Sistem daha önce dışarıya açıksa erişim geçmişine ve yapılandırma değişimlerine daha geniş bir aralıktan bakın.
Bu çalışma tek bir ekibin kontrol listesi olarak kalmamalı. Ağ ekibi dış erişim yollarını doğrularken platform ekibi düzeltme seviyesini kontrol edebilir; SOC ekibi de aynı dönemdeki kimlik doğrulama ve politika olaylarını bu bulgularla birleştirebilir. Üç ayrı rapor yerine ortak bir olay zaman çizgisi, parçalar arasındaki ilişkiyi görmeyi kolaylaştırır.
Yetkili hesapları da aynı gözle değerlendirin. Uzun süredir kullanılmayan yönetici hesaplarını kapatın. Servis hesaplarının haklarıyla erişim belirteçlerinin sürelerini yeniden gözden geçirin. Acil erişim hesabı kullanıldıysa işlem bitince parolasını veya ilgili gizli değeri yenileyin. Kalıcı ve geniş yönetim erişimi operasyonu kolaylaştırabilir, ama saldırganın işini de aynı ölçüde kolaylaştırır.
Güvenlik yönetim düzlemi sıradan bir uygulama sunucusu değildir; buradaki yetki birçok ağ geçidine ve güvenlik kuralına yayılır. Yönetim arayüzlerinin varsayılan olarak dış dünyaya kapalı olması gerekir. Acil erişim de kısa süreli, kimliği doğrulanmış ve kayda alınmış bir yol üzerinden verilmelidir.
SharePoint: yama sonrası makine anahtarı riskiBuradan dinle
SharePoint’te yamanın tek başına yetmemesinin nedeni de bu geçmiş erişim ihtimalidir. CVE-2026-50522, şirket içi SharePoint Server kurulumlarında kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya yol açabilen kritik bir seri durumdan çıkarma açığı. CISA bu açığı 22 Temmuz’da aktif istismar kataloğuna aldı. CERT-EU da internete açık sistemler için yama, kimlik bilgisi yenileme ve geçmişe dönük ihlal incelemesi çağrısı yaptı.
Yama ile olay müdahalesi arasındaki fark burada çok net. Sistem saldırıdan önce yamalanırsa risk önemli ölçüde azalır; ancak saldırgan yama öncesinde içeri girdiyse yalnız dosyaları değiştirmiş olmayabilir. Makine anahtarı uzun ömürlü, kritik bir sırdır; saldırgan yama öncesinde içeri girdiyse bu anahtarı da ele geçirmiş olabilir.
Makine anahtarı dışarı çıktıysa açığı kapatmak, geçmiş erişimin etkisini kendiliğinden ortadan kaldırmaz. Araştırma havuzundaki teknik telemetri bu nedenle anahtar yenilemenin ayrıca değerlendirilmesini öneriyor. CERT-EU’nun tavsiyesi de yama sonrasında kimlik bilgilerinin yenilenmesi ve geçmişe dönük ihlal incelemesi yapılması yönünde.
Bu konudaki belirsizliği de açıkça söyleyelim. Makine anahtarı hırsızlığı ayrıntısı, teknik telemetriye ve bu veriye dayanan analizlere dayanıyor; saldırganın kimliği ile doğrulanmış kurban sayısı bilinmiyor. Aynı duyuruda geçen diğer SharePoint açıklarını da kendiliğinden aktif istismar edilmiş sayamayız, çünkü her CVE için ayrı kanıt gerekir.
Savunma sırası şöyle kurulabilir: İlgili yamayı uygulayın, ardından ASP.NET ve SharePoint makine anahtarlarını bunlarla ilişkili kimlik bilgileriyle birlikte yenileyin. Microsoft IIS bileşenini kontrollü biçimde yeniden başlatın. Son adımda internet erişimini kaldırın ya da güçlü erişim kontrolüne alın.
Geçmişe dönük incelemeyi de başlatın. Beklenmeyen işlem oluşumlarını, web uygulaması altında çalışan sıra dışı komutları ve kalıcılık işaretlerini arayın; yalnızca antivirüs sonucuna güvenmeyin. Kimlik bilgisi kullanımı, IIS günlükleri ve sistem değişiklikleri ortak bir zaman çizgisinde karşılaştırıldığında çok daha anlamlı hale gelir.
Birden fazla SharePoint sunucusu varsa anahtar yenileme sırasını önceden planlayın. Hangi sunucuda hangi anahtarın yenilendiğini kaydedin; işlem bitince de her sunucunun gerçekten yeni değerle çalıştığını doğrulayın.
İnceleme sonunda bulgu çıkmaması da kayıt altına alınmalı. Hangi günlüklerin mevcut olduğunu, hangilerinin saklama süresi yüzünden artık bulunamadığını açıkça belirtin; çünkü kanıt yokluğu ile olay yokluğu aynı şey değildir. Kapsamı doğru yazmak, daha sonra yeni bir gösterge geldiğinde doğru sistemlere geri dönmeyi kolaylaştırır.
Xpoda: doğrulanmış düzeltme yokken risk kararıBuradan dinle
Doğrulanmış bir düzeltme henüz yokken de risk kararı gerekir. Türkiye’den gelen CVE-2026-2395 kaydı bunu gündeme getiriyor. Xpoda No Code Platform için yayımlanan bu kritik SQL enjeksiyonu kaydı, CVSS değerlendirmesinde on üzerinden 9,8 puan alıyor. Ulusal bildirim ile CVE kaydı bu sürüm aralığını doğruluyor: 4.3.1.0 ile 20260722 arasındaki sürümler etkileniyor. Bildirim sırasında üretici tarafından doğrulanmış bir düzeltme bulunmadığı için ulusal tavsiye, muadil ürün değerlendirmesini de gündeme getiriyor.
Yamasız bir açık, teknik ekibin tek başına çözeceği bir konu değildir; iş sahibi ve yönetimle birlikte geçici bir risk kararı gerekir. Önce Xpoda kurulumlarının sürümlerini, dışa açık uç noktalarını ve iş açısından taşıdığı veriyi belirleyerek gerçek bir envanter çıkarın.
Ardından erişimi daraltın. İnternete açık uçları mümkünse kapatın veya güvenilir ağlarla sınırlayın. WAF kurallarıyla günlük takibi geçici koruma sağlayabilir, ancak bunlar doğrulanmış bir yamanın yerini tutmaz. Uygulama kritik veriye erişiyorsa izolasyonla geçiş planını aynı anda yürütün.
Şu anda bu kayıt için aktif istismar raporlanmış değil; istismar telemetrisi, saldırgan bilgisi ve internet üzerindeki kurulum sayısı da bilinmiyor. Üreticinin yanıt vermediği bilgisi risk yönetimi açısından önemlidir, fakat tek başına sistemlerin ele geçirildiğini göstermez. Önceliği yüksek tutarken kullandığımız dili de bu kanıt seviyesine göre ayarlamalıyız.
Her geçici önlemin bir sahibi ve bitiş tarihi olsun. Eklenen WAF kuralının hangi isteği engellediğini test edin, günlük uyarısının gerçekten nöbetçi ekibe ulaştığını görün. Geçişe karar verirseniz, veri taşıma, entegrasyon ve geri dönüş adımlarını ayrı ayrı yazın. Belirsiz bir tarihe bırakılan geçici kontrol, zamanla görünmez ama kalıcı bir riske dönüşür.
Azure DevOps MCP ve yapay zekâ ajanı güveniBuradan dinle
Dördüncü konu, yapay zekâ ajanlarının ne zaman saldırganın aracına dönüşebileceği. Manifold Security araştırması, Microsoft'un Azure DevOps hizmetine bağlanan bir MCP sunucusunu inceliyor. Bu sunucuyu kullanan ajanlarda bir yetki aktarımı riski gösteriliyor. Araştırma, saldırganın yetkili aracı yanlış yönlendirebildiğini gösteriyor. Bir kod değişikliği isteğinin açıklamasına yerleştirilen görünmez HTML yorumu, ajanın bağlamına ham içerik olarak girebiliyor.
Ajan bu metni güvenilir talimat sanırsa incelemeyi yapan kişinin yetkileri saldırganın amacı için kullanılabiliyor. Bu nedenle asıl soru, ajanın hangi araçlara ve verilere erişebildiğidir. İncelemeyi yapan kişinin erişim belirteci birden fazla projeyi görebiliyorsa saldırganın yazdığı içerik, ajanı işlem hattına, vikiye, kaynak koda veya gizli değerlere yönlendirebilir. Ajan kötü niyetli değildir; ancak güvenilmeyen veriyle güçlü araçlar aynı bağlamda birleştiğinde saldırgan adına hareket eden yetkili bir aracıya dönüşebilir.
Çalışma, yöntemin iki farklı ajan üzerinde işlediğini bir kavram kanıtıyla gösteriyor. Araştırmacılar bulguyu Microsoft Güvenlik Yanıt Merkezi’ne bildirdi; merkez de bildirimi kabul ederek ön incelemeye aldı. Araştırma penceresinin sonunda henüz bir CVE açıklanmamıştı; doğrulanmış bir düzeltme de yoktu. Gerçek saldırılarda kullanıldığına ilişkin herhangi bir kanıt bulunmuyor. Gösterimin çalışması için saldırganın kod değişikliği isteği yazabilmesi, incelemeyi yapan kişinin daha fazla erişim yetkisine sahip olması ve otomatik onay yaklaşımının kullanılması gerekiyor.
Bu koşullar riski sıfırlamıyor, fakat kapsamı doğru anlatmamızı sağlıyor. Uzakta barındırılan MCP Server üzerindeki etkinin bir bölümü araştırmacı çıkarımıdır ve doğrudan test edilmiş değildir. Test edilen sonuçlarla olası genişlemeyi birbirine karıştırmamak gerekir.
Savunmada ajanın erişim belirteçlerini proje kapsamıyla sınırlayarak başlayın. Asgari yetki burada bir slogan değil, saldırının ulaşabileceği veri sınırıdır. Kod değişikliği isteği gibi güvenilmeyen veriyi sistem veya kullanıcı talimatından açıkça ayırın. Projeler arası okuma, işlem hattı çalıştırma, viki erişimi ve yorum gönderme gibi eylemler için de açık insan onayı isteyin.
Olay kaydında ajanın hangi içeriği okuduğunu, hangi aracı çağırdığını ve hangi kimlikle işlem yaptığını görmek gerekir. Yalnızca son cevabı kaydetmek yeterli değildir. Ara adımlar görünmezse olay incelemesinde davranışın nedeni de kaybolur.
Güvenlik testini birkaç kötü niyetli komutla sınırlamayın. Önce ajanın görebildiği projeleri, araçları, bellek alanlarını ve dış bağlantıları çıkarın; ardından saldırganın kontrol edebileceği içerikleri tek tek deneyin. Kod değişikliği isteği, iş kaydı, kaynak kodu yorumu ve dokümantasyon aynı güven seviyesinde kabul edilmemeli.
Başarısız görünen bir saldırı bile önemli olabilir. Ajan talimatı reddettiği halde hassas bir dosyayı okuduysa, son cevap güvenli görünse de veri sınırı aşılmıştır. Bu yüzden yalnız nihai metni değil, araç çağrılarını, okunan kaynakları, dışarı veri çıkarma denemelerini ve insan onay noktalarını birlikte değerlendirin.
Üretimde güvenli varsayılanlarla başlayın: Projeler arası erişim kapalı, yazma ve çalıştırma yetkileri birbirinden ayrı olsun. Yüksek etkili bir eylemden önce kullanıcıya anlaşılır bir özet gösterin. Onay ekranında yalnızca aracın adını değil, hedef projeyi ve taşınacak veri türünü de belirtin. Böylece insan onayı, düşünmeden basılan bir düğme olmaktan çıkar.
Haftalık savunma özetiBuradan dinle
Bu dört başlık aynı noktada birleşiyor: yüksek etkili yetkiler, yama kadar dikkat ister ve yönetim düzlemleri birçok sistemi etkileyebilir. Yama, geçmiş erişimin bıraktığı sırları temizlemeyebilir; yama yoksa geçici korumalar açık bir geçiş kararıyla desteklenmelidir. Yapay zekâ ajanlarında da güvenilmeyen içerikle güçlü araçlar arasına kesin sınırlar koymak zorundayız.
Bu haftanın uygulanabilir özeti şu: İnternete açık yönetim arayüzlerini yeniden sayın, kritik yamalardan sonra kimlik bilgilerinin yenilenmesi gerekip gerekmediğini sorun ve düzeltmesi olmayan ürünler için bir iş sahibiyle birlikte tamamlanma tarihi belirleyin. Ajan erişim belirteçlerini proje bazında daraltın; yüksek etkili araç çağrılarına anlaşılır insan onayı ve izlenebilir kayıt ekleyin.
Son olarak, kanıtın ne söylediğini ve ne söylemediğini ayırmak da savunmanın bir parçasıdır. Aktif istismar, kavram kanıtı ve yalnızca teorik risk aynı kategori değildir. Doğru sınıflandırma, ekibin enerjisini gerçekten acil olan yere yönlendirir.
KapanışBuradan dinle
Bu haftalık SIBERLAB podcastinin sonuna geldik. Sistemlerinizi güncel tutun, ama yamanın ötesinde kalan erişim izlerini de takip edin. Bir sonraki bölümde görüşmek üzere.