.NET Haziran 2026 Servis Güncellemesi: 3 CVE ve Bilmeniz Gerekenler
Aylık.NET servis güncellemeleri benim için, dürüst olayım, eskiden biraz “sonra bakarız” diye kenara atılan şeylerdi. Açıp kontrol eder, “tamam patch gelmiş, bunu da pazartesi konuşuruz” deyip kapatırdım. Ama son birkaç yılda tablo değişti. Hele bir de CVE duyuruları daha sıkı çıkmaya başlayınca ve etkilenen sürüm listesi uzadıkça, bu küçük görünen güncellemeler üretim ortamında en hayatı bakım pencerelerinden biri öldü (şaşırtıcı ama gerçek)
Bir şey dikkatimi çekti: Haziran 2026 sürümü de tam o kafada. Sessiz gibi dürüyor, ama boş değil..NET tarafında 3 yeni CVE kapanmış,.NET Framework tarafında işe bu ay yeni bir şey yok. Kulağa hafif sıkıcı geliyor, evet. Sız ne dersiniz? Ama işin içine girince, özellikle Türkiye’deki kurumsal yapılarda sık kaçan birkaç nokta var; onları biraz didikleyelim.
Bu Ay Neler Var? Kısa Özet
9 Haziran 2026 tarihli pakette üç ana sürüm elden geçmiş:
- .NET 10.0.9 — şu an LTS olarak desteklenen ana sürüm
- .NET 9.0.17 — STS sürümü, ömrü Mayıs 2026’da bitmek üzere (artık son düzlüğe girmiş durumda) (bence en önemlisi)
- .NET 8.0.28 — LTS, 2026 Kasım’a kadar destekleniyor — ciddi fark yaratıyor
Üç CVE de aynı anda bu üç sürümü etkiliyor. Yanı 8, 9, 10; hepsi kapsama girmiş durumda. Bu önemli bir ayrıntı çünkü bazı ekipler “biz hâlâ 8’deyiz, idare eder” gibi bir rahatlığa kapılıyor. Yok öyle değil. Eski LTS’te olmak sizi otomatik korumuyor, hatta bazen tam tersi oluyor.
Kapatılan CVE’ler
| CVE Numarası | Açıklama | Etkilenen Sürümler |
|---|---|---|
| CVE-2026-45591 | .NET Güvenlik Açığı | 10.0, 9.0, 8.0 |
| CVE-2026-45491 | .NET Güvenlik Açığı | 10.0, 9.0, 8.0 |
| CVE-2026-45490 | .NET Güvenlik Açığı | 10.0, 9.0, 8.0 |
Microsoft bu tip detayları her zamanki gibi biraz kontrollü yayımlıyor; yanı sömürü zinciri açık açık ortada değil. Ama benim genel okuma şeklim şu: üç ayrı CVE varsa ve üçü de aynı sürüm setini vuruyorsa, ortak bir runtime ya da BCL bileşenine dokunulmuştur demektir. Geçmiş aylardaki örneklere bakınca bunlar çoğu zaman serialization tarafına, kriptografi katmanına ya da HTTP/2 stack’ine bağlanıyor.
Peki neden?
“Patch çıktı, geçtim” demek yetmez. Container imajlarınız, base imajlarınız, sideload edilmiş runtime’larınız — hepsi ayrı ayrı güncellenmeli. Tek bir noktayı kaçırırsanız patch’i hiç geçmemiş gibi olursunuz.
.NET Framework Tarafında Sessizlik
Ne yalan söyleyeyim, Bu ay.NET Framework için ne güvenlik ne de güvenlik dışı yeni bir güncelleme yok. İlk bakışta rahatlatıcı dürüyor olabilir ama ben pek öyle görmüyorum. Açık söyleyeyim: Framework artık “stabil” çizgisinde değil; daha çok donmuş bir yapı gibi ilerliyor. Yeni özellik beklemiyorsunuz zaten, geriye sadece hayatı yamalar kalıyor.
Türkiye’de hâlâ aktif kullanılan Framework 4.8 / 4.8.1 tabanlı sistem sayısı az değil, hatta şaşırtıcı derecede yüksek diyebilirim. Daha açık söyleyeyim, hele bir de finans, kamu ve sigorta tarafında “çalışan sisteme dokunulmaz” refleksi çok baskın oluyor (hani bilirsiniz), ama burada küçük bir detay var: Windows Server 2012/2012 R2 üzerindeki ESU desteği de artık sona erdi sayılır; yanı Framework ayağa kalkıyor olabilir ama altındaki OS sizi ne kadar taşıyor, ona ayrıca bakmak lazım.
Eğer hâlâ Framework üzerinde hayatı bir uygulamanız varsa ve modernizasyon için net bir yol haritanız yoksa, .NET Day Agentic Modernization: Eski Uygulamalara Yeni Hayat yazımda anlattığım yaklaşımı bir kurcalayın derim (inanın bana). AI destekli modernizasyon araçları artık demo seviyesinde takılı kalmadı; valla iş görüyorlar.
Bu Patch’i Geçmeden Önce: Pratik Kontrol Listesi
Sahada en sık gördüğüm şey şu: ekipler patch’i ya fazla aceleyle geçiyor ya da gereksiz yere oyalanıyor. İkisi de sıkıntı çıkarıyor. Doğru akış bence şöyle ilerlemeli:
- Envanteri çıkarın — Hangi sunucu, hangi container, hangi Function App, hangi App Service hangi.NET sürümünde? Şaşırırsınız; çoğu kurumda bu bilgi güncel olmuyor.
- Bağımlılık matrisini görün — Bazı NuGet paketleri runtime sürümüne fazla hassas davranıyor; özellikle System.Text.Json ve gRPC istemcileri burada biraz nazlı.
- Staging’de smoke test yapın — Patch’i prod’a basmadan önce en azından 24 saat staging’de tutun; sorunların çoğu ilk 6-12 saatte yüzünü gösteriyor.
- Container imajlarını rebuild edin — mcr.microsoft.com/dotnet/aspnet imajını sadece pull etmek yetmez; kendi katmanlarınızı da yeniden derlemek gerekiyor.
- Rollback planı hazır olsun — Bu kısım hep atlanıyor nedense; hangi build hangi commit’ten geldi ve geri dönüşte ne lazım olacak?
Azure App Service ve Container Apps İçin Notlar
İşin garibi, Azure tarafında güzel olan şey şu: App Service (ki bu çoğu kişinin gözünden kaçıyor). Container Apps’in kendi runtime stack’i otomatik güncelleniyor gibi çalışıyor;. Sız “Stack Settings” altında “8.0” seçtiyseniz Microsoft o patch level’ı arkada taşıyor (en azından çoğu zaman). Ama işin küçük can sıkıcı tarafı var: bu otomatik geçiş bazen 2-4 hafta gecikebiliyor; can alıcı bir CVE varsa App Service’i restart etmek güncel runtime’a geçişi hızlandırabiliyor.
Eğer self-contained deployment yaptıysanız tablo değişiyor tabiî. Çünkü runtime’ı uygulamanın içine gömmüş oluyorsunuz. O noktada CI/CD pipeline’ında --self-contained true ile derleme yaparken base image’ı ya da SDK’yı elle güncellemeniz gerekiyor; yoksa Azure’un otomatik mekanizması size pek fayda etmiyor.
# Hızlı bir kontrol: hangi sürümler yüklü?
dotnet --list-runtimes
dotnet --list-sdks
# Container içinde kontrol için:
docker run --rm mcr.microsoft.com/dotnet/aspnet:8.0 dotnet --version
docker run --rm mcr.microsoft.com/dotnet/aspnet:9.0 dotnet --version
docker run --rm mcr.microsoft.com/dotnet/aspnet:10.0 dotnet --versionTürkiye’deki Kurumsal Yapılar İçin Özel Notlar
Kendi müşterilerimde gördüğüm kadarıyla Türkiye’de.NET patch yönetimi genelde iki uçta dolaşıyor: ya aşırı hızlı davranılıyor. Test yapılmadan prod’a yükleniyor (sonra “uygulama açılmıyor” mesajları başlıyor), ya da aylarca bekleniyor ve compliance denetimi kapıya dayanınca herkes panikliyor.
Bence daha dengeli yol şu: KOBİ veya orta ölçekli bir ekipseniz çıkış tarihinden yaklaşık 1 hafta sonra staging’e alın, 2 hafta sonra prod’a geçin. Enterprise tarafta. Regülasyona tabi yapılarda (BDDK ya da KVKK kapsamında kritik veri işliyorsanız) bunu biraz daha temkinli yürütmek lazım; mesela staging süresini uzatıp change advisory board onayıyla prod’a çıkmak daha sağlıklı oluyor.
Bir dakika — bununla bitmedi.
Bir de şu gerçek var: bazı kurumlarda hâlâ.NET 6 hatta.NET 5 üzerinde uygulama dönüyor olabiliyor; bunlar artık desteklenmiyor zaten. CVE çıktığında patch gelmeyebiliyor bile. Buradan açık konuşayım: 2026 ortasındayız; eğer hâlâ 6 ya da öncesindeyseniz bu ertelenecek konu değil artık.
.NET 11 Preview 5: Sessiz Gelen Yenilikler, Büyük Etki yazımda anlattığım gibi sürüm geçişlerini sürekli ötelemek hem güvenlik hem performans tarafında üst üste binen teknik borç yaratıyor.
Maliyet Tarafı: TL Bazında Nasıl Bakmak Lazım?
Patch işleri dışarıdan ücretsiz gibi görünür ama pek öyle değil aslında.
Bir orta ölçekli kurumda aylık.NET patch yönetimi maliyetini kabaca şöyle düşünebilirim:
- DevOps mühendisinin yaklaşık 4-8 saatlik mesaisi (envanter + uygulama + smoke test)
- Staging ortamının çalışma süresi (Azure’da ek VM/App Service maliyeti)
- Olası rollback ve incident response süresi
Bunun toplamı kabaca aylık 15-30 bin TL bandında bir kurumsal yük yaratabiliyor.
Azure Update Manager ya da GitHub Actions tabanlı otomasyonla bunu yarıya çekmek mümkün olabilir ama önce süreç düzgün kurulmalı; otomasyon ondan sonra geliyor, tersine değil.
mcr.microsoft.com/dotnet/aspnet:8_0` gibi sabit etiketler yerine,
GitHub Actions'da haftalık çalışan bir scheduled workflow kurun ve `docker pull` + `docker image inspect` ile imaj SHA'sını kontrol edin.
Değişiklik varsa pipeline'ı tetikleyin.
Container Imajları ve Linux Paketleri
Bu ay container imajları da yenilenmiş durumda.
`mcr.microsoft.com/dotnet/aspnet`, `runtime`, `sdk`. `runtime-deps` imajlarının hepsi yeni patch’leri içeriyor.
Kubernetes üzerinde çalışıyorsanız ki Türkiye’de AKS kullanımı son iki yılda gerçekten hızlandı,`imagePullPolicy: Always` ayarınıza ya da deployment’lardaki tag stratejinize yeniden bakmanız iyi olur.
Neyse uzatmayayım.
Linux paketleri tarafında `apt` ve `yum` repolarındaki paketler de
9 Haziran itibariyle taze.
Ubuntu
22_04** and **24_04**, RHEL **9**, Azure Linux **3_0** —
hepsi destekleniyor.
Küçük ama önemli not:
`dotnet-runtime-8_0` ile ``aspnetcore-runtime-8_0` paketleri ayrı ayrı geliyor;
ikisini de güncellemek gerekiyor.
Hep aynı hata yapılıyor:
insanlar sadece runtime’ı yeniliyor,
ASP.NET Core runtime eski kalıyor.
Tam da öyle.
Kişisel Görüşüm: Bu Ay Acil mi?
Vallahi, Açık konuşayım,
bu ayki CVE’lerin CVSS skorları henüz tam yayımlanmadı ama Microsoft’un tonuna bakınca “Critical RCE” seviyesinde bir şey olmadığını hissediyorum.
Yine de düşük risk demek değil;
üç CVE’nin aynı pakette gelmesi bana orta-yüksek bantta bir durum olduğunu düşünduruyor.
Peki neden?
Çünkü böyle toplu gelen yamalar genelde tek başına önemsiz olmaz.
Şimdi gelelim işin can alıcı noktasına.
Küçük bir detay: Bence bu ay işi iki hafta içinde kapatın.
Aceleye getirmeyin. Bekletmeyin de.
Mesela internete açık bir API host ediyorsanız (mesela ASP.NET Core Web API tabanlı bir backend), bunu öne alın.
Sadece intranet içinde çalışan bir Windows servisi varsa normal patch döngünüze koymanız yeterli olur.
Basit aslında (yanlış duymadınız)
Bak şimdi, Bir de şunu unutmayın:
Copilot Autofix Azure DevOps'ta: Alert Yığını Bitiyor mu?
yazımda anlattığım gibi dependency scanning’i pipeline’a bağladıysanız bu CVE’ler. Görünür hale gelir.
Dependabot ya da GitHub Advanced Security kullanıyorsanız önümüzdeki birkaç gün içinde PR’ların düşmeye başladığını görebilirsiniz.
Şey… buna hazırlıklı olun derim.
Sıkça Sorulan Sorular
.NET 9.0.17 son patch mi olacak?
Büyük ihtimalle hayır. Yani, 9.0'ın resmi destek süresi Mayıs 2026'da bitmişti aslında, ama güvenlik odaklı patch'ler hani biraz daha sürüyor (ben de ilk duyduğumda şaşırmıştım). Bence yine de 9.0'da takılı kalmayın — 10.0 LTS'e geçiş planınızı şimdiden hazırlayın. Önümüzdeki birkaç ay içinde son patch'i alırsınız.
.NET Framework 4.8.1'i hâlâ kullanıyorum, ne yapmalıyım?
Panik yapmayın, 4.8.1 desteklenmeye devam ediyor. Ama açıkçası uzun vadeli yol haritanızda Framework'ten çıkış büyük ihtimalle olmalı. Önce bir envanter çıkarın — hangi uygulamalar Framework'e gerçekten bağımlı, hangileri kolay taşınır, onu görün. Tecrübeme göre bazıları.NET 8'e bir haftada taşınıyor, bazılarını ise neredeyse sıfırdan yazmak gerekiyor.
Patch geçince uygulamam bozulur mu?
Major sürüm değişikliği yapmıyorsanız, yani mesela 8.0.x'ten 8.0.y'ye geçiyorsanız, breaking change ihtimali gerçekten çok düşük. Ama sıfır da değil. Bilhassa System.Text.Json, HttpClient, kriptografi katmanı gibi alanlarda ve bazı edge case'lerde davranış değişebiliyor. Bu yüzden bence staging testi atlamamanız gereken bir adım.
Azure App Service runtime'ını manuel güncelleyebilir miyim?
Vallahi, Hayır, doğrudan runtime'a dokunamıyorsunuz. Ama "Stack Settings" altından sürümü değiştirebilir ya da App Service'i restart ederek Microsoft'un sağladığı en güncel patch level'a daha hızlı geçebilirsiniz. Self-contained deployment kullanıyorsanız bu kural geçerli değil aslında — o zaman kendi base image'ınızı kendiniz güncellemeniz gerekiyor.
Container imajlarını ne sıklıkla pull etmeliyim?
En az aylık, ideal olarak haftalık otomatik kontrol. Bir de şunu söyleyeyim: production deployment'larınızda :latest tag'ini asla kullanmayın, mesela :8.0.28 gibi spesifik bir versiyonla pin'leyin. Otomatik güncelleme istiyorsanız bunu CI/CD üzerinden kontrollü yapın — runtime'a bırakmayın, açıkçası bırakırsanız sürprizlerle karşılaşabilirsiniz.
Kaynaklar ve İleri Okuma
.NET ve.NET Framework Haziran 2026 Servisleme Güncellemeleri (Resmi Blog) (evet, doğru duydunuz)
.NET 10.0.9 Release Notes (en azından benim deneyimim böyle)
.NET Sürüm Politikası ve Destek Takvimi
Microsoft.NET Container Imajları (Docker Hub)
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.
Yorum gönder