CISA'nın SharePoint ve RouterOS açıklarını aktif istismar kanıtıyla KEV kataloğuna eklemesi, bu haftanın bakım sırasını belirlemek için iyi bir başlangıç. Cloudflare'ın Containers incelemesi de sanal makine sınırının arkasında kalan disk bloklarını güvenlik değerlendirmesine katmak gerektiğini gösteriyor. 18–27 Eylül taramasından seçilen konuları okurken yama işleriyle özellik denemelerini ayrı tutmakta fayda var. İlkinde eldeki sistemlerin maruziyetini azaltmaya çalışıyoruz; ikincisinde henüz kendi ortamımızda ölçmediğimiz davranışları değerlendiriyoruz. Bu yazıda öncelik, bakım kararı vermek için gereken ayrıntılarda: hangi ürünün etkilendiği, bir kontrolün nerede uygulandığı ve eldeki verinin neyi söylemediği. Önerileri küçük testlere bölerek uygulamak, bütün duyuruları aynı anda altyapıya taşımaktan daha makul.
SharePoint ve RouterOS: önce erişimi ve yama durumunu doğrulayın
CISA'nın 25 Eylül duyurusu, SharePoint kod enjeksiyonu CVE-2026-65660 ile RouterOS iş akışı denetimi açığı CVE-2026-67279 için aktif istismar kanıtı bulunduğunu belirtiyor. Bu, envanterinde bu ürünler olan ekiplerin öncelik sırasını değiştirmesi için yeterli gerekçe.
Microsoft'un yayımladığı CVE kaydı, SharePoint açığını yetkili bir saldırganın ağ üzerinden kod çalıştırması olarak tanımlıyor; etkilenen ürünler Enterprise Server 2016, Server 2019 ve Subscription Edition. Aynı kayıtta etkilenen sürümlerin üst sınırları, hariç tutulmak üzere, sırasıyla 16.0.5565.1001, 16.0.10417.20198 ve 16.0.19725.20522 olarak veriliyor. Çiftlikteki her sunucunun build bilgisini ayrı doğrulayın; yalnız merkezi güncelleme işinin başarılı görünmesine güvenmeyin.
RouterOS tarafında CERT Polska'nın açıklaması, SSH yeniden anahtarlama sırasında kimlik doğrulama yapılmadan oturum kanalına geçilebildiğini ve yönetilen dosya alanında yetkisiz dosya işlemlerine izin verildiğini söylüyor. MikroTik, SSH erişimini güvenilmeyen ağlardan kapatmayı ve güncelleme sonrasında tanınmayan kullanıcılarla scriptleri incelemeyi öneriyor. Burada tek bir sürümü bütün açıkların çözümü diye önermek doğru olmaz: CERT Polska, aynı araştırmadaki ayrı bir RSA açığının ilk düzeltmesinin eksik kaldığını da kaydediyor. Kullandığınız sürüm dalının güncel düzeltmelerini kontrol edin; olay incelemesini yama kurulumunun bittiği yerde kesmeyin.
Cloudflare Containers: VM izolasyonu disk temizliğinin yerine geçmiyor
Cloudflare'ın 24 Eylül açıklamasına göre Containers ve onun üzerine kurulan Sandboxes, aynı fiziksel sunucudaki önceki iş yüklerinden kalan disk verilerinin okunabildiği bir açıktan etkilendi. Şirketin teknik incelemesi, Firecracker sanal makinelerine sunulan dm-thin disk havuzlarında skip_block_zeroing seçeneğinin açık olduğunu; küçük bir yazmanın yeniden tahsis edilen bloğun kalanını temizlemediğini anlatıyor.
Rapordaki sınırlar da önemli: saldırgan belirli bir müşteriyi seçemiyor, başka bir müşterinin aktif bağlı diskine erişemiyor; veri bulunması yerleştirme ve blokların yeniden tahsisine bağlı. Bunu bütün Cloudflare ürünlerine yayılan bir ihlal gibi okumamak gerekir.
Cloudflare, yeni tahsislerde sıfırlamayı geri getirmenin yanında eski çalışan diskleri ve önbellekteki imaj snapshot'larını da yenilediğini, düzeltme için müşteriden işlem beklemediğini bildiriyor. Şirketin kötü niyetli istismar bulamadığı yönündeki değerlendirmesi, elindeki geçmiş disk I/O telemetrisiyle sınırlı; bunu hiç veri okunmadığının garantisi sayamayız.
Paylaşımlı depolama işleten ekipler için pratik karşılığı şu: izolasyon testine kaynağın ikinci kiracıya devrini de ekleyin. Yalnız yeni oluşturulan temiz diski test etmeyin; silinmiş bir iş yükünün ardından yeniden kullanılan alanı da sınayın. İncelemeyi snapshot ve imaj önbelleklerini kapsayacak şekilde kurun, fakat üretim havuzunda davranışı belirsiz bir sıfırlama değişikliği yapmadan önce ayrı ortamda deneyin.
Docker Kit: ajan izinleri kod incelemesine girebilir
Docker, 24 Eylül'de duyurduğu Sandbox Kit Specification v3 ile ağ kuralları, kimlik bilgisi bağları ve diğer yetki taleplerini standart OCI imajının içine koyduğunu söylüyor. Duyuruya göre digest sabitlemek içerikle birlikte bu beyanları da sabitliyor; bir güncellemenin istediği ek erişimler incelemede görünür hale geliyor.
Geliştirme ya da CI ajanı işleten ekipler bunu izin değişikliklerini incelemek için deneyebilir. Kod deposuyla çalışan bir ajanın yeni bir dış alan adına erişim istemesini, sıradan bağımlılık güncellemesiyle aynı onaydan geçirmeyin. İmaj içeriğini inceleyen kişi bu talebi de görebilmeli.
Ancak Docker'ın kendi uyarısı açık: Kit kendine yetki vermiyor, kararı host alıyor; standarda uygun runtime yoksa imajdaki annotation herhangi bir kural uygulamıyor. Bu yüzden bir OCI imajını çekebilmek, izin politikasının çalıştığını kanıtlamaz. Küçük bir pilotta önce izin verilmeyen alan adına çıkışın gerçekten engellendiğini ölçün. Ardından bir güncellemeyle erişim kapsamını genişletmeyi deneyin ve onayın nerede istendiğini kaydedin. Bunları görmeden platform genelinde güvenlik kontrolü olarak kabul etmeyin.
Kubernetes PVC durumu: boşta olmak silinebilir olmak değil
Kubernetes'in 21 Eylül yazısı, v1.37'de PersistentVolumeClaimUnusedSinceTime özelliğinin varsayılan açık beta durumuna geçtiğini ve PVC'lere Unused koşulu eklendiğini açıklıyor. Koşulun tarifine göre çalışan veya Pending durumundaki pod referansı kullanıma sayılıyor; Succeeded ve Failed durumundaki podlar sayılmıyor.
lastTransitionTime, koşulun değiştiği zamanı veriyor; dosya sisteminin son okunma ya da yazılma zamanını ölçen bir alan değil. Kapasite raporu hazırlarken bu veriyi "diskte uzun süredir iş yapılmamış" diye yorumlamayın.
Önerim, ilk kullanımın silme otomasyonu yerine bir inceleme raporu olması. Uygulama sahibini bulup saklama ihtiyacını doğrulayın; yeniden çalışacak periyodik bir işin verisini yanlışlıkla artık kaynak saymayın. Onaylanan temizlik adaylarında yedeğin geri yüklenebildiğini de kontrol edin. Kümenizde bu koşul görünmüyorsa önce sürümü ve feature gate durumunu araştırın; alanın yokluğunu kullanımın olmadığı şeklinde ele almayın. Maliyet raporuna girecek bir sinyal ile geri dönüşü zor bir silme kararını ayrı tutmak daha güvenli.
Tailscale: performans duyurusu ile teslim edilen özellik farklı
Tailscale'in 22 Eylül yol haritası, subnet router, app connector ve exit node trafiğini CPU çekirdeklerine dağıtacak çoklu kuyruk çalışmasını anlatıyor. Şirketin takviminde Linux/Android tampon belleği iyileştirmeleri v1.104 için beklenirken, çoklu kuyruk bu sürümden sonraya planlanıyor. Yazıyı okuyup bugün kurulu istemcinin bunların tamamına sahip olduğunu varsaymayın.
Aynı duyurudaki netmap önbelleği, daha önce ağa katılmış cihazın diskinde tuttuğu haritayla kontrol düzlemine yeniden ulaşmadan bağlantı kurmaya başlamasını hedefliyor; ilk katılımın yerine geçmiyor. Tailscale, bu özelliğin mevcut istemcide bayrakla kullanılabildiğini, varsayılan açılışını ise ek testlerden sonra v1.104 için beklediğini belirtiyor.
Yoğun trafik taşıyan ağ geçitlerinde yükseltmeden önce karşılaştırma kaydı alın. Aynı uçlar arasında tek bağlantıyı ve eşzamanlı bağlantıları ayrı ölçün; CPU kullanımını da sonuca ekleyin. Doğrudan bağlantı ile röle üzerinden geçen testi birbirine karıştırmayın. Sonrasında aynı yükü yeniden çalıştırın. Şirketin performans beklentisini kendi donanımınız için kapasite taahhüdüne çevirmek yerine, satın alma kararını bu ölçüme dayandırın.
Transformers GGUF desteği: önce donanım sınırına bakın
Hugging Face'in 22 Eylül duyurusu, GGUF ağırlıklarını ggml çekirdekleriyle Transformers içinde sıkıştırılmış biçimde çalıştıran yolu tanıtıyor; başlangıç odağı Apple Silicon ve Qwen3.5 mimarisi. Belirtilen kısıtlar arasında paketli çıkarımın şimdilik MPS ile sınırlı olması ve kurulum için Transformers ana geliştirme dalının gerekmesi var.
Python üzerinden kuantize model değerlendirenler bu yolu deneyebilir. Linux/CUDA üzerinde çalışan mevcut bir yerel model servisini ise yalnız bu duyuruya dayanarak taşımayın. Hugging Face, uyumlu kuantizasyon çekirdeği bulunmazsa yükleyicinin ağırlıkları açıp daha çok bellek kullanabileceğini belirtiyor.
Denemede yalnız modelin cevap vermesine bakmayın. Hangi backend'in seçildiğini ve yükleme sonrasındaki bellek kullanımını kaydedin. Yayımlanan karşılaştırmada Transformers ölçümü prefill'i içerirken llama-bench sütunu yalnız decode hızını ölçüyor; dolayısıyla sütunları eş koşullu bir yarış gibi aktarmak doğru değil. Kendi karşılaştırmanızda aynı istemi ve çıktı uzunluğunu kullanın, ilk token gecikmesini ayrıca ölçün. Böylece geliştirme kolaylığının sizin iş yükünüzde neye mal olduğunu görebilirsiniz.
Bu hafta neye bakmalı?
- SharePoint sunucularını ve RouterOS cihazlarını envanterle eşleştirin. Dış erişimi kontrol edin; yama doğrulamasıyla şüpheli değişiklik incelemesini ayrı işler olarak takip edin.
- Paylaşımlı disk testlerine silme ve yeniden tahsis senaryosu ekleyin. Snapshot ve imaj önbelleklerini kapsam dışında bırakmayın.
- Ajan izinlerinin gerçekten uygulandığını küçük bir pilotta sınayın; izin genişleten güncellemenin onay beklediğini doğrulayın.
- Unused PVC'ler için önce sahiplik ve saklama raporu çıkarın. Silme kararı vermeden geri yükleme denemesini tamamlayın.
- Tailscale ve yerel model denemelerinde başlangıç ölçümlerini saklayın; planlanan özellikleri kurulu sürümün yetenekleri diye kaydetmeyin.
