Pazartesi sabahı, kahveyi daha yeni koymuştum ki bir bankacılık müşterimizin DevOps lideri aradı. “Aşkın bey, Patch Tuesday geldi,.NET tarafında 4 CVE var, bunlardan hangileri bizi gerçekten etkiler?” diye sordu. Açık konuşayım, bu soru artık ezber gibi. Her ayın ikinci salısı aynı hikâye. Ama bu pakette iş değişiyor; özellikle Elevation of Privilege tarafındaki CVE-2026-32177 biraz fazla geniş bir alana yayılıyor, hani ilk bakışta insan “bu kadarını da beklemiyordum” diyor.
Bu yazıda Mayıs 2026 servicing güncellemelerini sadece “şu sürüm çıktı, şunu indirin” diye geçmeyeceğim — valla güzel iş çıkarmışlar —. Önü zaten Microsoft’un release notes’unda okuyabilirsiniz. Ben size sahada bunları nasıl ele aldığımızı, hangi köşelerde takılabildiğimizi ve Türkiye’deki kurumsal yapılarda neden bazen işin kağıt üstündeki kadar düzgün gitmediğini anlatacağım (bizzat test ettim)
Önce Resmin Bütünü: Mayıs 2026’da Ne Geldi?
12 Mayıs 2026 itibarıyla hem.NET 8/9/10 hem de.NET Framework (3.5 ve 4.6.2’den 4.8.1’e kadar tüm aile) için servisleme paketleri yayınlandı. İçinde güvenlik düzeltmeleri var, güvenlik dışı düzeltmeler de var; yani klasik Patch Tuesday paketi diyebiliriz. Ama asıl dikkat çeken nokta şu: bu ay aynı CVE’nın (32177) hem modern.NET sürümlerini hem de eski Framework ailesini birlikte etkilemesi, işte bu biraz can sıkıyor.
Evet, doğru duydunuz.
Şöyle söyleyeyim, Bu önemli, çünkü bir kurumun envanterinde hem.NET Framework 4.7.2 üzerinde çalışan eski bir WCF servisi olabilir, hem de.NET 10 üstünde koşan modern bir mikroservis bulunabilir (inanın bana). İkisi de aynı anda patch’lenmeli. Geçen yıl bir telekom müşterisinde bunu eksik yapmıştık; modern tarafı yamalı sandık, eski Framework tarafı açık kaldı, sonra pentest ekibi üç hafta sonra üstüne başa başa raporladı — dürüst olayım, biraz hayal kırıklığı —
Bu Ayın CVE Tablosu
| CVE | Tür | Etkilenen | Aciliyet (Bence) |
|---|---|---|---|
| CVE-2026-32177 | Elevation of Privilege | .NET 8/9/10 + Framework 3.5–4.8.1 | Yüksek |
| CVE-2026-35433 | Elevation of Privilege | .NET 8/9/10 | Orta-Yüksek |
| CVE-2026-32175 | Tampering | .NET 8/9/10 | Orta |
| CVE-2026-42899 | Denial of Service | .NET 8/9/10 | Senaryoya bağlı |
“Aciliyet (Bence)” sütununu özellikle ekledim. Çünkü Microsoft’un CVSS skoru her zaman sizin ortamınızdaki gerçekliği yansıtmıyor, şey, bazen kağıt üstünde düşük görünen açık sahada daha tatsız olabiliyor. Mesela DoS açığı; eğer arkasında WAF, rate limiter, CloudFront ya da Front Door varsa bu sizin için orta seviyede kalır, (buna dikkat edin). Doğrudan internete açık bir Kestrel endpoint’ınız varsa tablo bir anda değişir.
Yeni Sürüm Numaraları ve Hızlı Doğrulama
Sahaya çıkan sürümler net:.NET 10 için 10.0.8,.NET 9 için 9.0.16,.NET 8 için 8.0.27. Peki nasıl bakacağız? Klasik komutlar iş görüyor, ama işin içinde küçük bir tuzak var.
# Yüklü runtime'ları görmek için
dotnet --list-runtimes
# Yüklü SDK'ları görmek için
dotnet --list-sdks
# Bir uygulamanın hangi runtime'ı kullandığını görmek (Linux)
dotnet --info | grep -A 2 "Host"Bak şimdi, dotnet --list-runtimes sana makinede ne kurulu olduğunu gösterir; güzel, tamam, ama uygulamanın gerçekten hangi sürümle koştuğunu tek başına söylemez. Self-contained deploy ettiyseniz olay biraz değişiyor, hatta baya değişiyor: runtime’ı güncel tutmanız tek başına yetmez, uygulama kendi içine gömülü olduğu sürümle çalışmaya devam eder. Yani patch geldi diye sevinmek erken olabilir (buna dikkat edin). Self-contained kullanıyorsanız patch’leme dediğiniz şey pratikte yeniden build ve redeploy demek (inanın bana). Framework-dependent tarafta işe sunucuyu güncellemeniz çoğu zaman yeterli oluyor.
Sahada en sık gördüğüm hata şu: Container imajlarını “mcr.microsoft.com/dotnet/aspnet:8.0” gibi major-version tag ile çekip “biz zaten günceliz” sanmak. Evet, kulağa mantıklı geliyor; ama image cache, Kubernetes pull policy, registry mirror gibi halkalardan biri araya girince eski imajla yaşamaya devam ediyorsunuz.
imagePullPolicy: Alwaysve digest pinning konusu da burada devreye giriyor, yani ayrı bir başlık açmak lazım.
.NET Framework Tarafı: Hâlâ Hayatta ve Hâlâ Önemli
Bir an durup şunu söyleyeyim: 2026’dayız ve hâlâ.NET Framework 3.5 için CVE patch’leri çıkıyor. Bu işin garip tarafı da bu zaten. Microsoft’un legacy desteği bu kadar uzayınca, kurumsal dünyada Framework’ün ne kadar derine yerleştiği daha net görünüyor.
Türkiye’deki kurumsal müşterilerimde tablo aşağı yukarı aynı. Bankalarda core sistemlerin ciddi bir kısmı hâlâ.NET Framework 4.7.2 ya da 4.8 üstünde koşuyor; sigorta tarafında işe iş biraz daha eski usul gidiyor, 4.6.2 üstündeki WCF servisleri, BizTalk entegrasyonları, arka tarafta sessizce çalışan ama kimsenin kolay kolay dokunmak istemediği parçalar… Bunların.NET 8/9’a göçü öyle “hadi taşıyalım” denecek iş değil, çünkü WCF Server’ı CoreWCF’e almak tek başına proje oluyor, üstüne bir de QA, regression test, ortam hazırlığı derken konu uzayıp gidiyor.
Ve işler burada ilginçleşiyor.
Dolayısıyla Framework patch’leri sadece “eski sistem” bakimi değil, aktif üretim ortamlarının güvenliği demek. Burada can alıcı nokta şu: Framework güncellemeleri Windows Update üzerinden geliyor,. Sunucu yaması ile uygulama yaması birbirine giriyor. İşte bu yüzden change management süreçleri zorlaşıyor; bir finans müşterimizde aylık bakım penceresi 3 saatti ve Framework patch, Windows kümülatif update, reboot derken bazen o pencere yetmiyordu bile. Sıkıştırmak için Cluster Aware Updating ya da rolling reboot stratejilerine yaslanıyoruz, başka çare kalmıyor.
Evet.
Framework Sürüm Matrisi: Nereden Nereye?
- 3.5: Hâlâ Windows Server üstünde feature olarak duruyor. SharePoint, eski BizTalk ortamları, legacy app pool’lar… Patch alıyor ama yeni feature gelmiyor.
- 4.6.2: En düşük “modern” Framework sürümü gibi düşünebilirsiniz. Windows Server 2016 ile gelen taban burada.
- 4.7 / 4.7.2: Sahada en sık gördüğüm sürümler bunlar, özellikle de 4.7.2. Hani bazı ortamlarda neredeyse varsayılan gibi duruyor.
- 4.8 / 4.8.1: Yeni projeler illa Framework’te kalacaksa çoğu zaman buraya geliyorlar. 4.8.1 ARM64 desteği getiriyor; küçük detay gibi duruyor ama bazı senaryolarda baya iş görüyor.
Şimdi, peki neden? Çünkü geçiş masrafı kağıt üstünde görünenden fazla oluyor.
Neyse uzatmayayım, işin aslı şu: Framework tarafını “bitti gitti” diye görmek pek gerçekçi değil; sahada yaşayan sistemler var ve onlar için patch yönetimi hâlâ gündemin tam ortasında duruyor. Bu konuyla ilgili etcd 3.7.0-beta.0 Yayında: RangeStream ve v2store Vedası yazımıza da göz atmanızı tavsiye ederim.
Patch’leme Stratejisi: Küçük Ekip vs Kurumsal
Bu konuyu sık sorunca, ben de ayrı bir başlık açayım dedim. Sahada iki ayrı dünya var; aynı patch yaklaşımını ikisine de zorla giydirmeye çalışırsanız, işin sonu pek hoş olmuyor. Bu konuyla ilgili MSVC’de SPGO Devri: Production’dan PGO Kalitesi yazımıza da göz atmanızı tavsiye ederim.
Küçük ekip / startup senaryosu
5-10 kişilik bir geliştirici ekibiniz varsa ve CI/CD üstünden haftada bir-iki kez deploy yapıyorsanız, işiniz nispeten rahat. Base image’ı güncellersiniz, pipeline’ı tetiklersiniz, staging’e gönderirsiniz, smoke test çalışır, sonra prod’a geçersiniz; çoğu zaman toplamda 1-2 saat yeter. GitHub Actions ya da Azure DevOps üstünde Dependabot benzeri bir bot bile bu işi sizin için açabiliyor.
İlk adımda şunları yapın: (1) Dockerfile’da base image tag’ınızı :8.0 gibi minor sabit, patch float bırakın, (2) build pipeline’a --pull ekleyin, (3) imajları Azure Container Registry’de tutuyorsanız “image cleanup” policy’sını açın ki eski imajlar gereksiz yere şişmesin. Basit görünüyor, evet; ama küçük ekipte zaten olay biraz da bu sadelikten yürür. Bu konuyla ilgili Azure NetApp Files EDA İçin: Bulutta Çip Tasarımı Devri yazımıza da göz atmanızı tavsiye ederim.
Şimdi gelelim işin can alıcı noktasına.
Enterprise senaryosu
Açık konuşayım, Burada tablo değişiyor, baya değişiyor (inanın bana). 200+ uygulamalı bir kurumsal ortamda change advisory board süreçleri var, donmuş dönemler var (yılbaşı, finansal kapanış, Ramazan-Kurban Bayramı kampanyaları), regresyon test beklentileri var; yani “Patch Tuesday geldi, akşama patch’leyelim” demek kağıt üstünde güzel duruyor ama pratikte pek işlemiyor.
Logosoft’ta bir bankacılık müşterimizde uyguladığımız akış şöyleydi: Pazartesi günü (Patch Tuesday öncesi) advisory’leri okuyup risk haritası çıkarıyoruz. Salı patch yayınlanınca aynı gün dev ortamına gidiyor. Çarşamba-Perşembe test ekibi smoke + regression koşuyor. Pazartesi gecesi UAT yapılıyor, sonraki hafta sonu prod’a alınıyor. Yani patch’in sahaya inişi yaklaşık 10-12 gün sürüyor. Başta bana yavaş gelmişti —. Bir kere bir patch yüzünden authentication akışı bozulunca anladım ki bu sabır boşuna değil.
Azure Tarafında: App Service ve Container Apps
Bir yerde kafa karışıyor, önü netleştireyim. Azure App Service’te.NET runtime kullanıyorsanız, patch işini Microsoft alıyor; siz ellemiyorsunuz. Ama uygulama self-contained işe iş değişiyor, o yük yine sizin omzunuza biniyor. Stack settings kısmında gördüğünüz sürüm de tam olarak bu yüzden önemli: orada aslında platformun auto-update ettiği Majör.Minor seviyesi duruyor, patch tarafı işe arkadan akıp gidiyor. Daha fazla bilgi için Azure IaaS Performans: Sistem Düzeyli Yaklaşımın Gücü yazımıza bakabilirsiniz.
Azure Container Apps ya da AKS tarafına geçtiğinizde tablo biraz tersine dönüyor. Base image’ı siz seçtiğiniz için, patch zincirinin başından sonuna kadar sorumluluk sizde kalıyor. Burada FinOps açısından küçük ama — itiraz edebilirsiniz tabi — can sıkıcı bir detay var: Container Registry’de bekleyen eski imajlar sessiz sessiz para yakıyor. Her ay yeni base ile build alıyorsanız ve cleanup policy kurmadıysanız, iki yıl sonra registry faturası kabardığında “bu nereden çıktı” diye bakakalabilirsiniz. TL bazında düşününce, ACR Premium SKU üstünde 100 GB storage ayda yaklaşık 2.500 TL ediyor; gereksiz imajlar bunu 3-4 katına rahat çıkarabiliyor (bizzat test ettim)
Şey, bir de şu var: konteyner tarafında Kubernetes v1.36: Silinemeyen Admission Politikaları Dönemi yazımda anlattığım admission policy’leri devreye aldıysanız, base image’ın belirli bir digest seviyesinin altına inemeyeceği kuralını koyabiliyorsunuz. Patch’i yapılmamış imajların prod’a sızmasını engellemek için baya iş görüyor.
Evet.
Kişisel Bir Hikâye: 2024’te Bir Patch’in Bana Yaşattıkları
2024 sonbaharında, bir e-ticaret müşterimizde rutin.NET 8 patch’i sonrası bir gecede HTTP/2 üstündeki trafik %15 düştü. Sebebini bulmamız tam 2 gün sürdü. Patch ile gelen bir Kestrel ayar varsayılanı değişmişti, gRPC client’larımızdaki connection multiplexing davranışı da bozulmuştu; çözüm tek satır config’ti. Önü bulana kadar ekip bayağı yıprandı, açık konuşayım.
Bu olaydan sonra kendime şu kuralı koydum: hiçbir patch’in release notes’unu “non-security fixes” diye geçiştirmem. Çünkü bazen security fix’in yanina sessizce eklenen davranış değişiklikleri insanı ters köşeye yatırıyor. Bu ayın non-security tarafında şu an gözüme çarpan bir şey yok, ama yine de staging’de 48 saat baskı testi görmeden prod’a çıkmıyoruz (yanlış duymadınız). Evet.
Bir Hatırlatma:.NET MAUI ve Diğer Workload’lar
Servicing release sadece runtime + ASP.NET Core + EF Core değil; SDK içinde gelen workload’lar da var, hani MAUI, WASM, benzeri parçalar ayrı bir dünya oluyor. Hele MAUI tarafında geçtiğimiz aylarda ciddi bir mimarı değişiklik oldu (o yazıda da anlatmıştım), .NET MAUI Artık CoreCLR’da: Mono Devri Kapanıyor. Mobil tarafa deploy yapan ekipler bu transition döneminde patch’leri biraz daha dikkatli okumalı, — bence çok yerinde bir karar —. Android/iOS workload sürümlerinde ufak gibi görünen davranış farkları çıkabiliyor; sonra herkes “bu niye böyle oldu?” diye birbirine bakıyor. Bu konuyla ilgili Kubernetes v1.36 Server-Side Sharded Watch: Saha Notları yazımıza da göz atmanızı tavsiye ederim.
Kısa bir not düşeyim buraya.
Pratik Bir Checklist
Bu ayın patch’ını güvenli şekilde uygulamak için kendi notlarımdan toparladığım sıra şu, hani çok süslü değil. Iş görüyor:
- Envanter çıkarın — hangi sunucuda hangi.NET sürümü var?
dotnet --list-runtimes+ WMI sorguları Framework tarafı için yeterince yol gösteriyor. - CVE haritasını çıkarın — sizin uygulamalarınızın hangileri etkileniyor? (Çoğunlukla hepsi, evet, biraz moral bozuyor ama gerçek bu.)
- Self-contained ile framework-dependent ayrımını netleştirin. Self-contained olanlar için rebuild planı yapmanız gerekiyor, yoksa iş sonradan uzuyor.
- Dev ortamına yamayı atın, sonra da kısa bir smoke test koşturun.
- Staging’de en az 24-48 saat bekletin. Kestrel davranışı, GC patterns ve allocation rate metriklerine bakın; bazen sorun ilk dakikada değil, birkaç saat sonra kendini gösteriyor.
- Prod’a kanarya deploy ile başlayın — bir node’da %5 trafik verin, 1 saat izleyin, sonra yavaş yavaş yaygınlaştırın.
- Rollback planı hazır olsun. Eski runtime ya da imaj elinizin altında dursun, çünkü bir şey ters giderse o kutu altın gibi oluyor.
Bu liste size biraz paranoyak gelebilir. Peki neden? Çünkü küçük bir ekipte 4-5-6-7 maddelerini tek seferde geçmek bazen mantıklı olabiliyor; ama enterprise tarafta aynı işler ayrı ayrı bakım penceresi istiyor, üstüne bir de gece yarısı telefonları geliyor.
Evet.
Burada, açık konuşayım, burada asıl mesele yamayı kurmak değil; neyin nerede kırılacağını önceden koklamak. Hani bir şey ölür da prod ortasında patlarsa diye değil, çoğu zaman sessiz sedasız performans kayması çıkıyor ortaya ve insan önü ancak metriklere bakınca fark ediyor.
Sıkça Sorulan Sorular
.NET servicing patch’lerini atlasak ölür mu?
Olmaz. Hani kümülatif yayınlanıyor diye “sonra toplu yaparım” deniyor ama atladığın her ay attack surface’in büyüyor. Bir CVE’nın PoC’si GitHub’a düştüğünde saatler içinde gerçek tehdide dönüşüyor. Bence 30 gün kuralını standart hâline getirmek en sağlıklısı.
.NET Framework 4.8 son sürüm mü, böyle mi kalacak?
4.8.1 son majör sürüm. Microsoft artık yeni feature geliştirmiyor, sadece güvenlik ve kritik bug fix geliyor (en azından benim deneyimim böyle). Açıkçası yeni projeler için.NET 8 veya üstüne geçmek şart. WCF Server gibi zorunlu bir bağımlılığın varsa CoreWCF göçünü şimdiden planlamaya başla, tecrübeme göre bu geçiş beklenenden uzun sürüyor.
Container imajım eski.NET sürümünde, sadece patch yeter mi yoksa rebuild mi gerekiyor?
Şunu söyleyeyim, Rebuild gerekiyor. mcr.microsoft.com/dotnet/aspnet:8.0 tag’ını kullanıyorsan her build’de güncel patch’i alırsın,. Imajı yeniden build etmezsen eski patch’le çalışmaya devam edersin. Yani CI pipeline’ına en azından ayda bir tetiklenecek bir cron schedule eklemen lazım.
Bu CVE’lerden hangisi en kritik?
Benim okumamla CVE-2026-32177. Hem modern.NET hem de Framework ailesini birden kapsıyor, yani saldırı yüzeyi çok geniş. Ayrıca privilege escalation açıkları başka bir zafiyetle zincirlenince RCE’ye dönüşüyor — bu kombinasyon gerçekten tehlikeli. Önceliği buraya ver.
Azure App Service otomatik patch’leniyor mu?
İtiraf edeyim, Runtime tarafı için evet, Microsoft hallediyor. Ama self-contained deploy ettiysen veya custom container kullanıyorsan sorumluluk sende. Stack settings’te “Minor version” seçtiysen patch float ediyor, “Specific minor” seçtiysen takıldığın sürümde kalıyorsun. Açıkçası bu ayarı bir kez daha kontrol etmekte fayda var, çoğu zaman fark edilmeden yanlış kalıyor.
Kaynaklar ve İleri Okuma
Araya gireyim: .NET and.NET Framework May 2026 Servicing Updates — Resmî.NET Blog Duyurusu
.NET Releases and Support Policy — Microsoft Learn
.NET Release Notes — GitHub dotnet/core Reposu
Microsoft Security Response Center — Update Guide
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
