Nisan yine geldi, hikaye de tanıdık: Salı günü Microsoft’un servicing paketi düştü, ben de kahvemi alıp CVE listesine bakarken bir anda altı tane güvenlik açığıyla karşılaştım. Altı. Geçen ay ikiymiş, ondan önce üç. Evet, sayı yukarı gidiyor ama panik yok; çoğu zaten “patch’i geç, devam et” sınıfında.
Lafı dolandırmadan gireyim: Eğer production’da.NET 8, 9 ya da 10 çalıştırıyorsanız — ya da hâlâ.NET Framework 4.8 ile yaşayan legacy bir sisteminiz varsa ki var, bunu Türkiye’de çok net görüyorum — bu ayki güncellemeleri es geçmeyin. Hele içlerinden biri RCE ise, o iş şakaya gelmez.
Bu Ay Masada Ne Var?
Araya gireyim: Önce resmi tabloyu bir kenara koyalım. Microsoft 14 Nisan 2026 itibarıyla hem.NET runtime ailesi hem de.NET Framework için kümülatif güncellemeyi yayınladı. Sürüm numaraları da şöyle duruyor:
| Ürün | Yeni Sürüm | Tür |
|---|---|---|
| .NET 10.0 | 10.0.6 | LTS |
| .NET 9.0 | 9.0.15 | STS |
| .NET 8.0 | 8.0.26 | LTS |
| .NET Framework 4.8 / 4.8.1 | Nisan CU | Windows Update |
.NET 10 artık ikinci servicing güncellemesini aldı; Kasım 2025’te GA olmuştu, şimdi biraz daha oturmuş durumda. Bir müşterimizde şu sıralar.NET 10 geçiş planı yapıyoruz — açık konuşayım, ben genelde bir LTS sürümün ilk iki üç servicing’i çıkmadan production’a alınmasını pek önermem,. Bazen ufak sürprizler çıkıyor (özellikle yoğun trafik alan servislerde). Ama bu sefer içim rahat; 10.0.6 bayağı yerine oturmuş görünüyor.
Doğrusu, Evet.
CVE’leri Tek Tek Açalım — Hangisi Kritik, Hangisi Panik Değil?
Microsoft’un CVE tablosu genelde kuru kuru geliyor; “şu versiyonlara etki ediyor” deyip bırakıyorlar. Peki hangisini önce yamalayacağız? Hangisi gerçekten baş ağrıtır? İşte burada biraz yorum lazım,. Her açık aynı kefeye konmuyor.
CVE-2026-33116 — Remote Code Execution (.NET 8/9/10)
Listenin en üstüne bunu koyuyorum. RCE varsa öncelik bellidir; uzaktan kod çalıştırabiliyorsanız gerisi detay kalıyor, hatta bazen detay bile olmuyor açıkçası. Microsoft henüz tam teknik detayı açmadı (responsible disclosure süreci bitene kadar genelde böyle yapıyorlar), ama etkilenen sürümler.NET 8,.NET 9 ve.NET 10 — yani modern stack’in tamamı diyebiliriz. E peki, sonuç ne oldu? Eğer internet’e açık bir ASP.NET Core API’niz varsa, bu ayki güncellemeyi önümüzdeki 48 saat içinde geçin derim; beklemeye değmez.
CVE-2026-32178 — Remote Code Execution (.NET +.NET Framework)
İkinci RCE de burada ve kapsamı daha geniş; hem modern.NET’i hem de Framework tarafını etkiliyor gibi görünüyor, yani kabaca Framework 2.0’dan 4.8.1’e kadar uzanan bir alan var karşımızda. IIS üzerinde çalışan eski bir WebForms uygulamanız varsa — ki evet, çoğu ortamda hâlâ var — bu CVE sizi de ilgilendiriyor demektir.
Türkiye’de bankacılıkta. Kamuda hâlâ.NET Framework 4.7.2 üstünde çalışan sistemler görüyorum; sayısı az değil hani, bayağı fazla bile diyebilirim.
CVE-2026-26171 — Security Feature Bypass
İsmi çok korkutucu durmuyor olabilir ama aldanmayın; “security feature bypass” dediğiniz şey aslında bir kontrolü atlayabilmek demek oluyor çoğu zaman (authentication mı olur, authorization mı olur, signature validation mı olur artık neyse). Teknik detay henüz tam açılmadığı için kesin konuşmak istemem. Bunu da yamalamak gerekiyor; orta-yüksek öncelik veririm ben buna (inanın bana)
CVE-2026-23666, CVE-2026-32203, CVE-2026-32226 — Denial of Service
Doğrusu, Üç tane DoS açığı var burada ve insanlar DoS görünce bazen omuz silkip geçiyor; yanlış refleks bence bu.
Bir saldırgan sizin API’nizi tek bir özel hazırlanmış request ile yere sererse iş durur.
Geçen yıl bir e-ticaret müşterimizde benzer bir şey yaşamıştık; o zaman CVE değildi ama JSON deserialization tarafında tuhaf bir edge-case vardı.
200 KB’lık payload ile CPU %100’e çıkıyordu.
Bu ayki DoS’lar da büyük ihtimalle parsing ya da serialization tarafındaki benzer pürüzlerden geliyor.
Çok konuştum, örnekle göstereyim.
“RCE bulununca herkes koşuyor, DoS olunca ‘yarın bakarız’ deniyor. Halbuki tek bir DoS Black Friday gecesi sistemi yere sererse, kayıp bazen RCE’den bile can yakıcı oluyor.”
Patch Önceliklendirme: Benim Önerdiğim Sıra
Hani, Kurumsal tarafta biz genelde küçük bir patch hiyerarşisi kuruyoruz. Büyük bir bankada aynı anda dört yüz tane.NET uygulamasını güncellemek kolay değil, hatta dürüst olayım çoğu zaman mümkün bile olmuyor.
- İnternet’e açık servisler (APIs, web uygulamaları): 48 saat içinde yama atın. En çok da RCE varsa beklemek yok.
- Partner entegrasyonları (B2B endpoint’ler): Bir hafta içinde toparlayın; dış erişim var ama en azından kontrollü ilerleyebilirsiniz. — ciddi fark yaratıyor
- İç sistemler (intranet, ERP, HR): İki üç hafta içinde alınabilir; test penceresi biraz daha rahat olur.
- Batch jobs, zamanlanmış görevler: Bir aya yayılabilir; yüzey alanı düşükse acele etmeyebilirsiniz.
Doğrusu, Bunu yirmi yıllık BT geçmişinden çıkardığım pratik bir yaklaşım olarak düşünün.
Mükemmel değil.
Ama baya iş görüyor (yanlış duymadınız)
Container Kullanıyorsanız İşiniz Daha Kolay
Eğer container kullanıyorsanız şanslısınız demektir.
Microsoft Container Registry’den (MCR) yeni imajları çektiğinizde runtime. Güncel gelir.
Mesela mcr.microsoft.com/dotnet/aspnet:8.0 gibi floating tag kullanıyorsanız iş çoğunlukla basit kalır: docker pull, sonra redeploy.
Bakın örnek aşağıda: Daha fazla bilgi için GitHub Status Sayfası Yenilendi: Şeffaflık Dönemi Başladı yazımıza bakabilirsiniz. Daha fazla bilgi için Azure MCP Visual Studio 2022’de: Eklenti Devri Bitti yazımıza bakabilirsiniz.
# Base imaj güncelleme örneği
docker pull mcr.microsoft.com/dotnet/aspnet:8.0
docker pull mcr.microsoft.com/dotnet/runtime:9.0
docker pull mcr.microsoft.com/dotnet/aspnet:10.0
# AKS için rolling update
kubectl set image deployment/api-service \
api=myregistry.azurecr.io/api:v2_3_1 \
--recordKüçük bir not düşeyim: SHA digest pinleme yapıyorsanız ki güvenlik açısından doğrusu budur, manifest’i elle yenilemeniz gerekir.
Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımda buna biraz daha girmiştim; oradaki multi-stage build yaklaşımı patch süreçlerini de hızlandırıyor aslında.
Neden Hâlâ.NET Framework 4.x Kullanılıyor?
Burası önemli.
Global Microsoft blogları yazınca genelde “Framework’ten çıkın, modern.NET’e geçin” diyorlar.
Kağıt üstünde haklılar.
Ama Türkiye’de sahaya indiğinizde tablo biraz değişiyor.
Geçen ay bir sigorta şirketiyle yaptığım toplantıda teknik mimar aynen şunu söyledi:
“Aşkın bey, biz bin dokuz yüz sekizden beri değil tabii ama iki bin sekizden beri.NET Framework üzerinde core sistem işletiyoruz.
Altı yüzden fazla iş mantığı var,
SQL Server’a gömülü stored procedure’lar var,
COM+ bileşenleri var…
Bunu.NET eight’e taşımak on sekiz ay sürer ve on dört milyon TL tutar.
Biz onun yerine her ay güvenlik yamasını geçiyoruz.”
Açık söyleyeyim haklıydı.
Her senaryoda modernizasyon çözüm olmuyor;
bazen sadece sistemi çalışır tutmak daha mantıklı geliyor.
Bu yüzden.NET Framework servicing güncellemelerinin devam etmesi ciddi rahatlık sağlıyor.
Microsoft’un 4\.8 ve 4\.8\.1 için güvenlik yamalarını yayınlamaya devam etmesi benim gözümde değerli.
En çok da kamu ve finans tarafında bağlılık yüksekken başka türlü yürütmek zor.
Tam da öyle (şaşırtıcı ama gerçek)
Ama sunucu ortamlarında çoğunlukla WSUS ya da SCCM üzerinden kontrollü dağıtım yapıyoruz.
Plansız restart istemezsiniz;
4 AM’de seksen sunucu aynı anda reboot ederse ertesi sabah hoş manzaralar çıkmaz.
Enterprise vs\. Startup : Farklı Yaklaşımlar
Küçük ekipseniz \(5 -20 geliştirici, az sayıda servis\) CI/CD pipeline’ınıza base image güncellemesini otomatik ekleyin.
Dependabot veya Renovate botları bu işi gayet yapabiliyor.
Haftada bir PR açılır,
otomatik test geçerse merge edilir.
Bitti gitti.
Büyük kurumsal yapıdaysanız ayrı bir “security patch window” tanımlayın.
Change advisory board’dan \(CAB\) her ay otomatik onay geçsin ;
sadece Microsoft resmi patch’i olduğunu doğrulayan hafifçe sıkı ama sade bir süreç kurun.
Bürokrasi azalır,
hız artar.
Kısacası, geçen yıl bir telekomda bunu kurduk ;
CAB toplantısı haftada iki saatten yirmi dakikaya indi,
şaşırdım açıkçası.
Ve işler burada ilginçleşiyor. net konusundaki yazımız yazımızda bu konuya da değinmiştik.
Test Stratejisi — “Yamaladım, Olduğu Gibi Production’a”
Bir bakıma, hayır.
Lütfen yapmayın.
Ben de ara sıra böyle davranıp sonra pişman oluyorum.
Şunu fark ettim: Servicing güncellemeleri genelde geriye dönük uyumlu \(backward compatible\) olacak şekilde test ediliyor ama “genelde” kelimesi burada kilit nokta.
2023’te \.\ NET six’ın bir servicing release’i HttpClient davranışında ufak bir değişiklik getirmişti;
connection pooling tarafında incecik ama can sıkıcı bir fark oluşmuştu.
Bizim servislerden biri bundan etkilenince sabah üçte SRE’yi uyandırdım.
Hoş anılar arasında saymam.
Benim önerdiğim minimum test seti şu:
- Smoke test : Uygulama ayağa kalkıyor mu ?
Temel endpoint’ler \`200\` dönüyor mu ?
On dakikalık iş, uzatmaya gerek yok. - Integration test : External dependency’ler \(SQL, Redis, Service Bus\) düzgün konuşuyor mu ?
Mesela TLS handshake’te değişiklik varsa bunu hemen yakalar.
(bu kritik) - Load test \(opsiyonel ama tavsiye\) : Baseline performance’ta yüzde ondan fazla regression var mı ?
k6 ya da NBomber ile kısa test yeterli olur çoğu zaman.
(bu kritik)
Staging ortamında yirmi dört kırk sekiz saat bekletin.
Bazen runtime seviyesindeki memory leak ya da GC davranışı değişikliği ancak saatler sonra ortaya çıkıyor;
ilk beş dakikada belli olmuyor yani.
Neyse, çok dağıttım, konuya geri dönelim.
(kendi tecrübem)
Azure App Service ve AKS Kullanıcıları İçin Notlar
Azure App Service’te \.\ NET runtime’ını Microsoft yönetiyor.
Bu tarafta kısmen işiniz kolaylaşır.
“Stack Settings” bölümünde minor version’ı “Latest” bırakırsanız Microsoft otomatik yamalar,
ama küçük detay şu :
bu otomasyon app restart demek olabilir.
Production için Deployment Slots kullanın ;
staging slot’ta yeni runtime test edilsin,
sonra swap yapılsın.
Açıkçası, AKS tarafında ise iş biraz daha manuel ilerliyor;
node image ayrı,
pod içindeki runtime ayrı düşünülecek.
Node image otomatik güncellense bile pod’unuzdaki \.\ NET runtime base image’a bağlı kalıyor.
Azure DevOps Advanced Security: Tek Tıkla CodeQL Devri\ yazısında bahsettiğim dependency scanning yaklaşımı burada da işe yarıyor ;
her build’de otomatik CVE taraması yapıp kritik patch’leri erken yakalayabiliyorsunuz.
Evet.
Maliyet Perspektifi : Patch Yönetimi Ücretsiz Değil
Burası çoğu zaman atlanıyor.
Güvenlik yamalarını “bedava iyi şey” gibi görüyoruz. Gerçek hayatta maliyet var :
test,
deploy,
rollback ihtimali,
bir de gece yarısı gelen telefonlar… hepsi bedel.
- D e v e l o p e r zamanı \(test, deploy\) :\ Ortalama ekipte ayda sekiz — on altı saat
- >Staging/test ortamı Azure maliyeti :\ Küçük kurumda ayda iki yüz — beş yüz TL
- >Potansiyel downtime riski :\ Değişken ama ucuz değil
) Orta ölçekli işletmede yıllık patch yönetimi kabaca kırk — seksen bin TL’lik iş yüküne dönüşüyor.
Kulağa fazla gelebilir ;
ama ransomware maliyetinin yanında deryada damla kalıyor.
Türkiye’de geçen yıl yayınlanan raporlarda ortalama kurtarma maliyetinin sekiz milyon TL’yi geçtiği söyleniyordu.
Pratik Aksiyon Planı — Bugün Yapılacaklar
Kısaca listeleyeyim,
uzatmaya gerek yok :
- Kullandığınız \.\ NET sürümlerini envanterden çıkarın ; `
`dotnet --list-runtimes``
her sunucuda kontrol edin.
- This month’s CVE listesine karşı etkilenen servisleri tek tek işaretleyin.
Sıkça Sorulan Sorular
.NET 6 kullanıyorsam ne olur?
.NET 6, Kasım 2024’te EOL oldu — yani artık güvenlik yaması almıyorsunuz. CVE’ler sizin için de geçerli ama maalesef fix gelmiyor. Bence en kısa sürede.NET 8 LTS’e geçmek gerekiyor; tecrübeme göre migration genellikle oldukça sorunsuz gidiyor, major breaking change pek çıkmıyor.
Çok konuştum, örnekle göstereyim.
.NET Framework 4.8’i daha ne kadar kullanabilirim?
Bir şey dikkatimi çekti: Microsoft resmi olarak “indefinite support” açıkladı. Yani belirsiz bir tarihe kadar güvenlik yamaları gelmeye devam ediyor. Aslında bu destek Windows Server’ın lifecycle’ıyla iç içe geçmiş durumda — onun desteği devam ettiği sürece sorun yok. Ama yeni feature beklemeyin. Mevcut sistemler için güvenli, ancak açıkçası yeni bir proje için hiç önermem (buna dikkat edin)
Otomatik güncelleme ne kadar güvenli?
Geliştirme ortamında? Bence evet. Production’da? Hayır. Her zaman staging’de en az 24 saat test etmeli, sonra canary deployment ile kademeli geçmelisiniz. Mesela otomatik güncellemeyi production’da kullanacaksanız deployment slot veya blue-green ile kombine etmek şart — aksi halde sürprizlerle karşılaşabilirsiniz.
Container imajımı güncelleyince uygulama kodunu da yeniden build etmem gerekiyor mu?
Evet, gerekiyor. Multi-stage Dockerfile kullanıyorsanız imajın tamamını rebuild etmeniz lazım, çünkü hani runtime değişti. CI/CD pipeline’ınızda base image hash değiştiğinde otomatik rebuild tetiklemek bence en temiz çözüm.
Hangi CVE’yi önce yamalamalıyım?
Öncelik sırası şöyle: CVE-2026-33116 ve CVE-2026-32178 birinci sıraya giriyor — ikisi de RCE, yani acil. Sonra CVE-2026-26171 geliyor, o da bir security bypass açığı. DoS açıkları (23666, 32203, 32226) üçüncü sırada (buna dikkat edin). Sakın ihmal etmeyin; trafik yoğun servislerde etkisi gerçekten büyük olabiliyor.
Kaynaklar ve İleri Okuma
.NET and.NET Framework April 2026 Servicing Updates — Resmi Microsoft Blog
.NET Release Support Lifecycle — Microsoft Learn
Microsoft Security Response Center — CVE Detayları ve Güncelleme Rehberi
Küçük bir detay: .NET Core Release Notes — GitHub Repository
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.
