Bu haftanın bakım planında ilk sırayı RouterOS ve GitLab'a ayırmak gerekiyor: CISA, bu ürünlerdeki açıkları aktif istismar kanıtıyla KEV kataloğuna eklediğini 10 Eylül ve 11 Eylül duyurularında bildirdi. Yeni özellikleri denemeden önce internete açık kurulumların durumunu netleştirmeyi öneriyorum. Yükseltme kararı verirken cihazın veya uygulamanın kime hizmet verdiğini, bakım kesintisini kimin üstleneceğini de kayda geçirmek gerek. Bu sayıda acil yamaların ardından bağlantı yönetimi ve gözlemleme değişikliklerine, sonra otomatik erişim düzeltmesiyle TLS tercihlerine bakıyoruz. Bu işleri aynı değişiklik penceresine sıkıştırmak yerine ayırmak daha makul. Özellikle erişimi kendiliğinden değiştirecek bir politikayı devreye alırken, yanlış kararın nasıl fark edileceğine ve geri alınacağına da zaman ayırın.
RouterOS: yamadan sonra yapılandırmayı da inceleyin
CISA'nın RouterOS kaydı, CVE-2026-67277'yi kritik bir işlevde eksik kimlik doğrulama, CVE-2026-86060'ı ise komut argümanı ayraçlarının uygunsuz işlenmesi olarak tanımlıyor ve her ikisi için aktif istismar kanıtı bulunduğunu belirtiyor. MikroTik'in güvenlik bülteni, düzeltmenin 7.24.2, 7.23.4, 6.49.21 ve 7.25 beta 3 sürümlerinde yer aldığını söylüyor. Üretim cihazını sırf listede var diye beta kanalına taşımayın; kullandığınız sürüm dalının düzeltilmiş sürümünü seçin.
Üretici, çoğu yapılandırmanın risk altında olmadığını belirtse de ayrıntılı koşulları aynı sayfada tam olarak açıklamıyor. Yalnız cihazın evde ya da ofiste olmasına bakarak kapsam dışında kaldığını varsaymayın. Envanterde RouterOS sürümünü ve güvenilmeyen ağlardan erişilebilen yönetim servislerini birlikte kaydedin. Güncelleme penceresi açılana kadar gereksiz dış yönetim erişimini kapatmayı değerlendirin.
MikroTik ayrıca SSH erişiminin güvenilmeyen ağlara kapatılmasını, günlüklerdeki "Flagged" durumunun kontrolünü ve bu işaret bulunmasa bile yükseltmeden sonra bilinmeyen kullanıcılarla scriptlerin incelenmesini istiyor. Ağ ekibinin değişiklik kaydıyla güvenlik ekibinin incelemesini aynı cihaz kimliği üzerinden eşleştirin; "güncellendi" kaydı, incelemenin de tamamlandığı anlamına gelmesin.
GitLab: dosya okuma açığı için bakım beklemeyin
GitLab'ın 10 Eylül bültenine göre CVE-2026-85706, belirli koşullarda kimliği doğrulanmamış bir kullanıcının repository commits API üzerinden sunucudaki dosyaları okuyabilmesine izin veriyor. CISA'nın ertesi günkü KEV eklemesi, bu açığın aktif olarak istismar edildiğini doğruluyor.
Etkilenen CE/EE aralıkları 18.7'den başlayıp 19.1.8'in öncesine uzanan sürümler, 19.2 dalında 19.2.6 öncesi ve 19.3 dalında 19.3.2 öncesi olarak veriliyor. GitLab, 19.1.8, 19.2.6 ve 19.3.2 düzeltmelerini yayımladığını; GitLab.com'un yamalı olduğunu ve Dedicated müşterilerinin işlem yapması gerekmediğini belirtiyor. Öncelik, kendi GitLab kurulumunu işleten ekiplerde.
Yükseltmenin operasyonel maliyetini de hesaba katın: bülten, veritabanı geçişleri nedeniyle tek düğümlü kurulumlarda kesinti olacağını söylüyor. Yedek ve bakım duyurusunu hazırlarken olay incelemesini ertelemeyin. Dosya okuma olasılığını temel alarak uygulama ve proxy günlüklerini koruyun; şüpheli erişim bulursanız okunmuş olabilecek dosyalardaki sırların yenilenmesini olay kapsamına alın. Bunlar inceleme önerileri; her kurulumda veri sızıntısı yaşandığını varsaymıyorum. Açığı uzaktan kod çalıştırma diye etiketlemeden, üreticinin tarif ettiği etki üzerinden hareket etmek gerekiyor.
Tailscale Operator: bağlantı yolunu ölçerek yükseltin
Tailscale'in 9 Eylül tarihli Operator 1.102 duyurusu, yeni PeerRelay kaynağıyla küme içinde relay kurulup Operator tarafından yönetilebildiğini bildiriyor. Şirket aynı sürümde ProxyGroup Egress için IPv6 hedef desteği ve çakışan IPv4 ağlarına 4via6 üzerinden erişim desteği eklediğini söylüyor; kümenin IP ailesinden kaynaklanan yönlendirme sınırlarının ise sürdüğünü açıkça belirtiyor.
Birden fazla VPC veya Kubernetes kümesi işleten ekipler için bunu önce bağlantı topolojisi işi olarak ele almak daha yararlı. Güncellemeden önce ve sonra örnek iş yükünün hangi yoldan gittiğini kaydedin. Relay eklemeyi tek başına performans kanıtı saymayın; gecikmeyi ve aktarım hızını kendi trafiğinizle karşılaştırın. Relay kaybında bağlantının davranışını ayrıca sınayın. Çakışan adres alanlarında özellikle uygulamanın kullandığı hedefi deneyin, yalnız test Pod'unun başarılı bağlantısıyla yetinmeyin.
Sertifika tarafında şirket, yenilemelerde backoff ve Retry-After kullanımını, Ingress silinirken gereksiz sertifika alımının engellenmesini anlatıyor; hız sınırlarına yine de takılınabileceğini not ediyor. Geçici ortamları sık açıp kapatıyorsanız başarısız sertifika taleplerini yükseltme kabul testine ekleyin. Yazıdaki iş yükü kimliği ve yeni CNI mimarisi ise gelecek çalışmaları arasında; erişim tasarımını henüz teslim edilmemiş özelliklere bağlamayın.
Native histogram geçişinde alarm kurallarını unutmayın
Kubernetes'in 11 Eylül yazısı, native histogram desteğinin 1.37'de beta olduğunu ve varsayılan açıldığını bildiriyor. Aynı açıklamaya göre bileşenler klasik bucket'ları da sunmayı sürdürüyor; native biçimi toplamak ise Prometheus tarafındaki yapılandırmaya bağlı. Küme yükseltmesiyle gözlemleme geçişini ayrı işler olarak takip edin.
Veri toplayıcıdaki ayara dikkat: resmî geçiş uyarısı, native toplama açılırken always_scrape_classic_histograms: true ayarı korunmazsa klasik _bucket, _count ve _sum serilerinin alınmasının durabileceğini söylüyor. Eski sorguları yeni veriye taşımadan bu ayarı kaldırmak, izleme geçişini gereksiz yere riskli hale getirir.
Prometheus işleten ekipler bir scrape job'ında iki biçimi birlikte toplayarak başlayabilir; önemli gecikme panellerini ve SLO alarm ifadelerini yan yana değerlendirin. Sonra test koşulunda alarmın gerçekten tetiklendiğini görün. Depolama kazancını eski seri alımını kapattığınız aşamada ölçün. Duyurudaki tasarruf beklentisini kendi ortamınızın sonucu gibi bütçeye yazmayın; geçiş süresince iki biçimi saklamayı da planınıza dahil edin.
Cloudflare CASB: otomatik düzeltmeye dar kapsamla başlayın
Cloudflare, CASB politikalarıyla yeni bulgulara göre paylaşım erişimini kaldırma veya webhook gönderme işlemlerinin otomatik tetiklenebildiğini duyurdu. Şirketin belirttiği mevcut yerel düzeltme kapsamı, Microsoft ve Google Workspace dosya/klasör bulguları; entegrasyon yetkilerini okuma-yazmaya yükseltmek gerekebiliyor. Alacağınız hizmeti bu kapsam üzerinden değerlendirin.
SaaS güvenliğini yöneten ekip için karar, hangi bulgunun insan onayı olmadan erişim değiştirebileceği. Önce dar bir entegrasyonda yalnız webhook üreten politika çalıştırmayı öneriyorum. Yanlış eşleşmeleri ve iş gereği dışarı açılan dosyaları inceleyin; ardından otomatik erişim kaldırmayı seçilmiş bulgulara açın. Politika sahibini ve yanlış kapatılan paylaşımın nasıl geri alınacağını önceden belirleyin. Yetki artışını sıradan bir kurulum adımı gibi geçmeyin.
Cloudflare, politika tanımındaki değişiklikler için yönetim günlükleri, çalıştırma sonuçları için ayrı kayıtlar tuttuğunu ve tespitten düzeltmenin tamamlanmasına kadar beş dakika veya altını hedeflediğini söylüyor. Bu süreyi garanti edilmiş SLA olarak aktarmamak gerekiyor. Kabul testinde başarılı işlerin yanında yetki hatası ve API hız sınırı durumlarını da deneyin; politikanın varlığına değil, hedef SaaS üzerindeki gerçek erişim durumuna bakın.
Origin TLS: otomatik tercih ile zorunlu politikayı ayırın
Cloudflare'ın Automatic Key Exchange duyurusuna göre sistem, TLS 1.3 destekleyen origin'leri tarayıp desteklenen anahtar anlaşmasını öğreniyor ve mümkün olduğunda X25519MLKEM768 hibritini tercih ediyor. Şirket bunun Cloudflare ile origin arasındaki bağlantıyı etkilediğini belirtiyor; ziyaretçinin Cloudflare'a bağlantısı ayrı. Web altyapısını yöneten ekipler incelemeyi doğru TLS sonlandırma noktasında yapmalı.
Duyurudaki önemli uyarı, post-kuantum hibrit zorunluluğu açıldığında origin X25519MLKEM768 desteklemiyorsa tüm TLS 1.3 bağlantılarının başarısız olacağı. Uyumluluğu doğrulamadan zorunluluk kutusunu açmayın; özellikle birden fazla arka uç kullanan alan adlarında her TLS sonlandırıcıyı ayrı sınayın.
Cloudflare ayrıca, Radar'a proxy arkasındaki alan adı verildiğinde testin origin yerine Cloudflare bağlantısını ölçtüğünü hatırlatıyor. Test hedefini seçerken bu ayrımı kayda geçirin. Şirketin gecikme kazanımı ölçümleri yeni el sıkışmalara ilişkin; mevcut keep-alive bağlantıları bundan etkilenmiyor. Kendi değerlendirmenizde yeni origin bağlantılarının hata ve el sıkışma sürelerini izleyin; toplam sayfa hızını tek kabul ölçütü yapmayın.
Bu hafta neye bakmalı?
- RouterOS cihazlarını sürüm ve yönetim erişimiyle eşleştirin; yükseltmenin yanına yapılandırma incelemesi için ayrı sorumlu atayın.
- Kendi işlettiğiniz GitLab'ın düzeltme kapsamını kontrol edin; kesinti planını hazırlarken günlükleri koruyup şüpheli dosya erişimini araştırın.
- Operator yükseltmesi için bağlantı yolu ve sertifika hatası testleri hazırlayın. Histogram geçişinde ise klasik serileri kapatmadan önce alarm testini tamamlayın.
- CASB düzeltmesini dar kapsamda deneyin; yanlış kapatılan paylaşımın geri alınmasını ve başarısız işlemin takibini sınayın.
- Origin'in gerçek TLS yeteneklerini doğrulayın; otomatik algoritma tercihiyle zorunlu post-kuantum politikasını ayrı değişiklikler olarak kaydedin.
