.NET Framework Mayıs 2026 Güvenlik Güncellemeleri
Mayıs yamaları bazen sessiz geliyor, ama etkisi baya gürültülü oluyor. Özellikle.NET tarafında tablo tam böyle; bir sabah ekip “sadece servis güncellemesi” diye bakıyor, öğlene doğru güvenlik ekibi, DevOps, uygulama sahipleri ve test ekibi aynı masada buluşuyor. İşin aslı şu: kağıt üstünde küçük duran sürümler, kurumsal ortamda domino etkisi yaratabiliyor.
Ben de yıllardır Azure ve.NET tarafında çalışırken şunu net gördüm: güncellemeyi son güne bırakan ekipler genelde iki şey yaşıyor; ya beklenmedik bir uyumluluk sürprizi çıkıyor ya da güvenlik ekibi kapıyı çalıyor. Geçen yıl Nisan 2025 civarında bir finans müşterisinde benzer bir yamayı geceye bırakmışlardı, sabah IIS uygulamasında ufak bir davranış farkı yüzünden geri dönüş planını açmak zorunda kaldık. Küçük olay gibi dürüyor, ama prod’da küçük diye bir şey yok.
Bu ayın özeti: Sessiz ama önemli bir bakım türü
.NET ve.NET Framework Mayıs 2026 servis güncellemeleri tek cümlede özetlenebilir: sistemi biraz daha güvenli, biraz daha stabil hâle getiriyor. Ama tabi bu “biraz” kısmı kurumsal tarafta baya can alıcı olabiliyor. Çünkü özellikle üretimde çalışan API’ler, arka plan işler, Windows servisleri ve eski nesil web uygulamaları söz konusuysa ufak görünen yamalar bile operasyonel riski azaltıyor.
Bu ay yayımlanan paketlerde hem güvenlik düzeltmeleri hem de güvenlik dışı iyileştirmeler var. Microsoft’un duyurusunda tarih olarak 12 Mayıs 2026 referans veriliyor. Burada dikkatimi çeken nokta şu öldü: desteklenen ana sürümlerin tamamına dokunulmuş olması. Yanı sadece en yeni dalga değil; 10.0, 9.0 ve 8.0 çizgisi birlikte ele alınmış.
Çok konuştum, örnekle göstereyim.
İşin garibi, Böyle aylarda ben hep aynı soruyu sorarım: “Kurulum yapmazsak ne olur?” Cevap çoğu zaman dramatik değil… ta ki biri CVE taramasında kırmızı görüp seni toplantıya çağırana kadar. Bir telekom müşterisinde Ocak 2024’te bunu yaşadık; runtime paketi birkaç hafta eski kalınca vulnerability management aracı alarm yağdırdı — bence çok yerinde bir karar —. Teknik sorun değildi aslında, süreç sorunu çıktı.
Hangi açıklar kapanmış?
Küçük bir detay: Bu sürümde birkaç önemli CVE kapatılmış durumda. Bazıları yükseltilmiş ayrıcalık riski taşıyor, bazıları tampering yanı manipülasyon riski içeriyor, biri de hizmet reddi tarafına gidiyor. Açık konuşayım: bunların isimleri sıradan görünüyor ama etki alanları hiç sıradan değil.
| CVE | Konu | Etkilenen Sürümler |
|---|---|---|
| CVE-2026-32177 | .NET Elevation of Privilege Vulnerability | .NET 10.0, 9.0, 8.0 ve.NET Framework birçok dal |
| CVE-2026-35433 | .NET Elevation of Privilege Vulnerability | .NET 10.0, 9.0, 8.0 |
| CVE-2026-32175 | .NET Tampering Vulnerability | .NET 10.0, 9.0, 8.0 |
| CVE-2026-42899 | .NET Denial of Service Vulnerability | .NET 10.0, 9.0, 8.0 |
İtiraf edeyim, Burada özellikle yükseltilmiş ayrıcalık sınıfındaki açıklar beni daha çok düşünduruyor. Kurumsal ortamlarda tek başına çalışan uygulama yok artık; kimlik bilgileri var, service account’lar var, secret vault bağlantıları var (bizzat test ettim). zincir uzuyor da uzuyor.
Şimdi gelelim işin can alıcı noktasına.
Güncelleme yapmamak bazen “şimdilik sorun yok” gibi görünür; sonra denetim zamanı gelir ve o küçük erteleme koca bir operasyon yüküne dönüşür.
Bi saniye — Geçen martta Ankara’daki bir müşteri ortamında tam da buna benzer bir durum vardı; geliştirme ekibi “önce test edelim” dediği için yama üç hafta gecikti. Sonuçta güvenlik taraması ile release takvimi birbirine girdi (hani klasik). İyi haber şu ki çözüm büyük değildi: önce staging’de kısa smoke test yaptık, sonra prod’a geçtik.
Sürüm numaraları ne söylüyor?
.NET tarafı nasıl dağılıyor?
Bu ayın sürüm numaraları net:.NET 10 için **10\.0\.8**,.NET \(9\) için **9\.0\.16**,.NET \(8\) için **8\.0\.27** geliyor.
Bunlar kulağa teknik rakam gibi gelebilir ama pratikte anlamı şu: aynı ana sürüm çizgisinde kalan kullanıcılar için bakım hattı devam ediyor demek.
Küçük ekiplerde bu çoğu zaman basitçe “upgrade yap geç” şeklinde ilerliyor.
Enterprise yapılarda işe iş biraz daha uzun; çünkü bağımlılıklar fazla oluyor (özellikle NuGet paketleri ve legacy bileşenler).
Durun, bir saniye.
.Framework tarafını neden hâlâ konuşuyoruz?
Neyse… burada biraz dürüst olayım: herkes yeni dünyaya geçti sanıyor ama sahada durum öyle değil.
Benim gördüğüm bankacılık. Kamu projelerinde hâlâ ciddi miktarda “.NET Framework” var.
2019’da İzmir’de bir sigorta projesinde WCF tabanlı katman yüzünden framework bağımlılığına takılmıştık; modernizasyon planı güzel görünüyordu ama işin göbeğinde eski kod vardı.
İşte bu yüzden framework yamaları hafife alınmamalı.
Sahada benim önerdiğim yaklaşım ne?
Açık konuşayım: ben bu tip aylık servis yayınlarında üç aşamalı ilerlemeyi seviyorum.
İlk adım inventory çıkarmak.
Hangi uygulama hangi runtime üzerinde çalışıyor?
İkinci adım staging doğrulaması.
Üçüncü adım işe kontrollü prod yayılımı.
Basit gibi dürüyor ama şaşırtıcı biçimde birçok ekip bunu atlıyor.
- Önce sunuculardaki mevcut runtime versiyonlarını topla.
- Paketlerin bağımlılıklarını kontrol et (NuGet dahil).
- Kritik uygulamalar için kısa smoke test seti hazırla. — ciddi fark yaratıyor
- Mümkünse canary veya ring deployment uygula. (bu kritik)
Bakın, Bence burada en hayatı konu hız değil disiplin. Az önce hız dedim ama aslında tam tersi daha doğru olabilir:
güncellemeyi hızlı yapmak yerine doğru sırayla yapmak gerekiyor. Bir Azure danışmanı olarak bunu defalarca gördüm;
hızlı yapılan iş bazen iki saat kazandırır,
ama ertesi gün sekiz saat kaybettirir.
Küçük startup ile enterprise aynı mı davranmalı?
Hayır.
Küçük startup iseniz genelde tek repo, az servis. Bu ne anlama geliyor? Sade dağıtım vardır;
o yüzden güncelleme penceresi kısa tutulabilir.
Ama enterprise tarafta finansal etki büyüyor,
denetim süreçleri var,
onay akışları var,
bağımlılık matrisi var…
iş uzuyor da uzuyor (bu konuda ikircikliyim) Daha fazla bilgi için
Doğrusu, Bütçe açısından bakarsak da tablo farklıdır. Azure’da çalışan container tabanlı yapılarda runtime güncellemesini ihmal etmek doğrudan para yakmayabilir;
ama incident çıktığında insan saati maliyeti yükselir. TL bazında düşününce mesele şu oluyor:
birkaç saatlik önleyici çalışma,
bazen bir haftalık kriz yönetiminden ucuz çıkıyor. Bir müşteri hesabında bunu kaba hesaplamıştık;
yaşanan kesinti olsaydı yalnızca altyapı değil satış kanalı da etkileniyordu…
Nerede dikkat etmek lazım?
İnanın, Beni en çok düşündüren noktalardan biri uyumluluk meselesi oluyor.
Sorunsuz yama diye çıkan şey bazen üçüncü parti paketle çatışabiliyor.
Eski ASP.NET bileşenleri, özellikle özel auth akışları olan projelerde, beklenmedik davranış gösterebiliyor.
Bu yüzden “update and pray” yaklaşımı bana göre pek iyi fikir değil.
Ben ilk denemede ne hata aldım?
Az önce her şey yolunda dedim. Gerçek hayatta öyle olmadı.
Haziran 2024’te kendi lab ortamımda.NET runtime güncellemesi sonrası IIS app pool recycle sırasında garip bir “.dll load” hatası gördüm.
Neydi sebep?
Bağımlılık paketlerinden biri eski kalmıştı.
Uzun uğraştırmadı gerçi; ilgili package version’u hizalayınca sorun çözüldü.
Burada ders basit:
runtime upgrade ile application dependency upgrade’i birlikte düşünmek gerekiyor.
Bana göre bu sürümün asıl mesajı ne?
Asıl mesaj bence çok net: platformu canlı tutmak lüks değil zorunluluk.
Microsoft’un aylık servicing ritmi zaten bunu hatırlatıyor
ve iyi ki de hatırlatıyor
Çünkü üretimde koşan sistemler müze eseri olmamalı—nefes almalı, yenilenmeli, temizlenmeli.
p>\
Ben AZ-305 hazırlığı yapan ekiplerle çalışırken de aynı şeyi söylerim:
kullandığınız mimarı sadece bugün işe yarıyorsa yeterince iyi değildir;
yarın patch geldiğinde de ayakta kalmalıdir( pardon )
manzara budur yanı.
Kendi deneyimimden konuşuyorum, Eğer sizde hâlâ “biz geçen aya kadar iyiydik” yaklaşımı varsa durup yeniden bakın derim.
Bilhassa dışarıya açık API’leriniz varsa bu update’i geciktirmek riskli olabilir.
Yine de her şeyi körlemesine yüklemek yerine önce test edin.
Kağıt üstünde süper görünen bazı yamalar pratikte ekstra regresyon çıkarabiliyor — biraz hayal kırıklığı yaratabiliyor açıkçası.
Sıkça Sorulan Sorular
. NET Mayıs \\２０２６ servicing update zorunlu mu?
Zorunlu kelimesi kulağa sert geliyor, ama açıkçası üretimde çalışan sistemler için neredeyse “evet” diyebilirim. Güvenlik açıkları kapanıyor hani, özellikle internet-facing uygulamalarda geciktirmemek iyi oluyor.
Öne çıkan değişiklik güvenlik mi?
Şimdi, küçük bir detay: Evet, bu pakette ana vurgu güvenlik düzeltmeleri. Ama. Sadece CVE kapatmıyorsunuz — bunun yanında non-security fixes de geliyor, yanı runtime davranışı da bir miktar toparlanıyor.
Test ortamına kurmadan prod’a geçmek mantıklı mı?
Bence pek mantıklı değil. İlginç, değil mi? En azından kritik uygulamalar için kısa bir smoke test şart; aksi hâlde ufak uyumluluk farkları sizi gece yarısı uğraştırabiliyor, tecrübeme göre bu hiç de nadir değil (ciddiyim)
. NET Framework kullanan sistemlerde ekstra risk var mı?
Evet, özellikle legacy bileşenler, WCF, özel auth akışları veya eski NuGet bağımlılıkları varsa dikkat etmek gerekiyor. Aslında eski olduğu için güvende sanılıyor ama tam tersi olabiliyor — bu konuda gerçekten dikkatli olmak lazım.
Kaynaklar ve İleri Okuma
Microsoft Learn -.NET yenilikler sayfası
Microsoft Security Update Guide
Ayrıca ilgili okuma olarak şuralara da göz atabilirsiniz:
NuGet Paket Budaması: Daha Temiz.NET Bağımlılıkları
.NET 11 Preview 4: Sessiz Ama Dolu Gelen Sürüm
Azure DevOps Server Mayıs Yamaları: Neyi, Neden, Nasıl Kontrol Etmeli?
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.
2 comments