.NET 10 Data Protection Güvenlik Açığı ve Acil Yama

Q: Container ortamında ne yapmalıyım?

Base image'ınızı mcr.microsoft.com/dotnet/aspnet:10.0.7 olarak güncelleyin, image'ları rebuild edip deploy edin. Rolling deployment yapıyorsanız tüm pod'ların yeni image ile ayağa kalktığından emin olun — yarım yamalak bir geçiş istemezsiniz.

⏱️ 9 dk okuma📅 22 Nisan 2026👁️ görüntülenme

Geçen hafta bir müşteriden gece yarısı telefon geldi. “Uygulamalar decrypt edemiyor, cookie’ler çözülmüyor, kullanıcılar sürekli oturumdan atılıyor.” İlk aklıma sertifika tarafı geldi, ya da key ring rotasyonu; hani klasik Data Protection derdi. Ama değilmiş. Meğer.NET 10.0.6 ile gelen bir regresyon, ASP.NET Core Data Protection katmanını sessizce bozmuş, üstelik işin garibi bu kırılma bir güvenlik açığını da ortaya çıkarmış.

Microsoft bunu fark edince Patch Tuesday’i beklemedi. Doğrudan out-of-band olarak.NET 10.0.7’yi yayınladı. CVE-2026-40372 kodlu bu zafiyet, “elevation of privilege” sınıfında yer alıyor. Kulağa ağır geliyor ama işin aslı şu: uygulamanızdaki şifreli verilerin doğrulaması beklediğiniz gibi yapılmıyor. Pek hoş değil.

Sorunun Kökeni: HMAC Doğrulaması Nerede Patladı?

Bakın şimdi, ASP.NET Core Data Protection mekanizmasını bilmeyenler için kısa keseyim. Bu sistem, cookie şifreleme, anti-forgery token üretimi, session yönetimi gibi hayatı işlerin arkasındaki kriptografik temel; yanı kullanıcı oturumunu tutan, form güvenliğini ayakta tutan o sessiz katman. Peki neden önemli? Çünkü uygulamada “ben bunu sonra düşünürüm” dediğiniz yer genelde tam burası oluyor.

Data Protection bir veriyi şifrelerken, aynı anda o verinin bütünlüğünü de kontrol etmek için HMAC (Hash-based Message Authentication Code) hesaplıyor. Normal akışta bu HMAC payload’ın tamamı üzerinden çıkıyor ve şifreli verinin yanına ekleniyor; çözme sırasında da önce bu kontrol çalışıyor, veri kurcalandıysa işlem direkt reddediliyor — bence çok yerinde bir karar —. Kulağa düz geliyor ama işin aslı biraz daha sert.

Güzel bir mekanizma, evet. Ama.NET 10.0.0’dan 10.0.6’ya kadar olan sürümlerde managed authenticated encryptor, HMAC’i payload’ın yanlış byte’ları üzerinden hesaplıyordu; yanı elinizde 1024 byte’lık bir şifreli veri varsa ve hash’in oradan çıkması gerekiyorsa, sistem gidip başka bir dilime bakıyordu (nasıl olduysa artık), üstüne bir de hesaplanan hash’i sonra çöpe atıyordu. Garip mi? Evet. Ama olmuş.

Bunu biraz açayım.

Yanlış byte’lar üzerinden HMAC hesaplanması + hesaplanan hash’in discard edilmesi = hem bütünlük doğrulaması çalışmıyor, hem de yetki yükseltme riski doğuyor. Kağıt üstündeki güvenlik mekanizması pratikte devre dışı kalmış oluyor.

Bir saldırgan bu açığı kullanırsa ne olur? Şifreli payload’ı değiştirir, sistem de çoğu durumda bunu fark edemez; sonra iş dönüp dolaşıp başka bir kullanıcının oturumunu çalmaya, yetki yükseltmeye ya da admin erişimi almaya kadar gider. En çok da multi-tenant uygulamalarda bu tablo hiç hoş değil, hatta baya sıkıntılı. Neyse uzatmayayım; riskin adı açıkça güven sınırının kırılması.

Kimler Etkileniyor? Hızlı Bir Kontrol Listesi

Ne yalan söyleyeyim, Herkes paniklesin demiyorum, ama net konuşayım: eğer.NET 10 kullanıyorsanız ve ASP.NET Core Data Protection’a bir yerden bağlıysanız — çoğu ASP.NET Core uygulamasında bu iş zaten bir köşeden çıkıyor — bu konu sizi doğrudan ilgilendiriyor. Bazen geliştirici arkadaşlar “ben Data Protection kullanmıyorum ki” diyor. Dur bir saniye, şunlardan biri var mı?

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Cookie-based authentication (varsayılan şablonda geliyor) (bu kritik)
Anti-forgery token’lar (@Html.AntiForgeryToken() ya da [ValidateAntiForgeryToken]) (bu kritik)
TempData (cookie-based provider ile) (bence en önemlisi)
Session middleware
Herhangi bir IDataProtector.Protect/Unprotect çağrısı (bence en önemlisi)

Bunlardan birini bile kullanıyorsan, Data Protection senin uygulamanın içinde sessizce çalışıyor demektir. Hmm, şöyle bakınca biraz gizli kahraman gibi dürüyor,. Işin aslı o kadar da masum değil; yeni proje açıp hiçbir şeyi ellemeden ilerlediysen bile,.NET 10 tarafında varsayılan middleware pipeline içinde bu mekanizma devrede kalıyor.

Sürüm Bazında Etkilenme Durumu

NuGet Paket Sürümü	Etkilenme Durumu	Aksiyon
10.0.0 — 10.0.6	⚠️ Etkileniyor	Hemen 10.0.7’ye güncelle
10.0.7+	✅ Güvenli	Aksiyon gerekmez
9.x ve altı	✅ Etkilenmiyor	Aksiyon gerekmez (bu sürümlerde farklı implementation)

Bir şey dikkatimi çekti:.NET 9. Öncesinde farklı bir encryptor hayata geçirmeu kullanıldığı (belki yanılıyorum ama) için bu zafiyet onları etkilemiyor. Ama burada küçük bir parantez açayım:.NET 9’un LTS desteği devam ediyor olsa da, sız.NET 10’a geçtiyseniz geri dönmek yerine güncelleme yapmak çok daha mantıklı; açık konuşayım, çoğu ekip için en temiz yol bu oluyor.

Güncelleme Nasıl Yapılır? Adım Adım

Lafı gevelemeden gideyim. İş basit görünüyor, ama production tarafında bir iki ayrıntı var, hani insanın sonradan “keşke şuna da baksaydım” dediği türden şeyler.

SDK veya Runtime Güncelleme

# Mevcut sürümünüzü kontrol edin
dotnet --info
#.NET 10.0.7 SDK'yı indirin ve kurun
# https://dotnet.microsoft.com/download/dotnet/10.0
# Kurulumu doğrulayın
dotnet --list-sdks
dotnet --list-runtimes
# Uygulamalarınızı yeniden derleyin
dotnet build
dotnet publish -c Release

Container kullanıyorsanız, ki Türkiye’deki enterprise müşterilerimizin çoğu artık Kubernetes üstünde dönüyor, base image tarafını da elden geçirmeniz gerekiyor. mcr.microsoft.com/dotnet/aspnet:10.0 tag’i çoğu zaman güncel patch’i çekiyor, ama açık konuşayım ben yine de sürümü net yazmayı seviyorum; mesela mcr.microsoft.com/dotnet/aspnet:10.0.7 gibi (evet, doğru duydunuz)

Sadece NuGet Paketi Güncelleme

Eğer SDK’yı hemen yükseltemiyorsanız, en azından NuGet paketini güncelleyin:

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Ha bu arada, uygulamanızda Microsoft.AspNetCore.DataProtection.Extensions ya da Microsoft.AspNetCore.DataProtection.StackExchangeRedis gibi yan paketler de varsa, onları da aynı anda güncelleyin. Geçen hafta tam da böyle bir işte, ana paket yeni sürüme geçmişti ama extension paketi eski kalmıştı; sonra sorun bitmedi tabii, çünkü asıl dert orada saklanıyormuş. Daha fazla bilgi için Codex Kurumsal Ölçekte: Ne Vaat Ediyor, Ne Eksik? yazımıza bakabilirsiniz.

💡 Bilgi: Güncelleme sonrası mevcut Data Protection key ring’inizdeki anahtarlar geçerliliğini koruyor. Yanı kullanıcılarınızın oturumları düşmeyecek; üstüne bir de 10.0.6’dan gelen decrypt hataları toparlanacak. İki kuş bir taşla.

Türkiye’deki Kurumsal Yapılar İçin Özel Notlar

Açık konuşayım, Şimdi işin en can sıkıcı ama en can alıcı tarafına gelelim. Türkiye’de, özellikle bankacılık. Finans ekipleriyle epey vakit geçiriyorum; bu tip acil güvenlik yamalarında mesele sadece “dotnet add package” komutunu çalıştırmak olmuyor, hatta çoğu zaman tam tersine, paketler doğrudan nuget.org’dan çekilmiyor, arada private feed’ler var, artifact repository’ler var, bir de üstüne approval zinciri geliyor. Bu konuyla ilgili Kubernetes’te AI Agent Sandbox: Pratik Rehber yazımıza da göz atmanızı tavsiye ederim.

Durun, bir saniye.

Logosoft’ta bir bankacılık projesinde aynısını yaşadık. 2024’te benzer bir OOB güncelleme geldiğinde, müşterinin iç güvenlik ekibinin paketi onaylaması üç gün sürdü; üç gün boyunca production ortamında bilinen bir zafiyet açık kaldı. Kulağa basit geliyor ama değil. Bu yüzden ben şunu öneriyorum:

Güvenlik yamalarını (özellikle CVE içerenleri) hızlandırılmış onay sürecine alın
Private NuGet feed’ınızı otomatik senkronize eden bir mekanizma kurun — Azure Artifacts bunu destekliyor
CI/CD pipeline’ınızda güvenlik taraması varsa (mesela Snyk, Dependabot, WhiteSource), bu araçlar zaten sizi uyaracaktır ama beklemeyin, proaktif olun (bence en önemlisi)

Bir de şu detay var: Türkiye’deki şirketlerin hatırı sayılır kısmı hâlâ.NET Framework ya da.NET 6/8 üzerinde koşuyor..NET 10’a henüz geçmediyseniz bu zafiyet sizi etkilemiyor gibi görünebilir, evet; ama bu “rahatız” anlamına da gelmiyor. Eski sürümlerde başka açıklar çıkabiliyor, yanı iş bitmiş sayılmaz. Daha önce Azure SDK Nisan 2026: Kritik Güvenlik Yaması ve Yenilikler yazımda benzer bir güvenlik yaması sürecini anlatmıştım; oraya da bakabilirsiniz.

Enterprise vs Küçük Ekip: Farklı Stratejiler

Bir bakıma, ne yalan söyleyeyim, Küçük bir startup’sanız, ya da 2-3 kişilik bir ekiple dönüyorsanız, iş genelde rahat akıyor. SDK’yı güncellersiniz, build alırsınız, deploy edersiniz; biter. On beş dakika sürer, bazen daha da az. Ama enterprise tarafında tablo biraz değişiyor.

Durun, bir saniye.

Büyük kurumlarda onlarca microservice oluyor, işte orası biraz karışıyor. Hepsinde Data Protection kullanılıyorsa ve shared key ring’ler Azure Blob Storage ya da Redis’te tutuluyorsa, güncellemeyi rolling deployment ile yapmanız gerekiyor (tüm servisleri aynı anda zıplatmaya kalkmayın), çünkü 10.0.7 ile şifrelenen veriyi 10.0.6 farklı şekilde çözmeye çalışabiliyor; hatta bazen bozuk çözüm davranışı yüzünden işler iyice saçmalıyor. Daha fazla bilgi için Kubernetes’te Production Debug Güvenliği: Rehber yazımıza bakabilirsiniz. Cosmos DB Dynamic Data Masking: Veri Güvenliğinde Yeni Dönem yazımızda bu konuya da değinmiştik.

Ben olsam şöyle giderdim: önce key ring’e erişen tüm servislerin listesini çıkarırım. Sonra downstream’den upstream’e doğru tek tek güncellerim, yanı zinciri tersinden yürütürüm; monitöring’i açık bırakır, decrypt hatalarını izlerim, bir yerde sapma görürsem de hemen frene basarım. Genelde bir saat içinde fleet toparlanıyor. Bu konuyla ilgili SQL Server 2025’te Güvenlik ve MCP: Tek Motor Yeter mi? yazımıza da göz atmanızı tavsiye ederim.

Küçük ekipseniz fazla kasmayın — tek bir dotnet publish, üstüne Azure App Service’e deploy, olay kapanıyor (eh, fena değil). Hani şu Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor yazımda anlattığım otomatik tarama pipeline’ı var ya, işte tam böyle durumlarda baya iş görüyor; insanın elini kolunu boş yere yormuyor.

Bu Olay Bize Ne Öğretiyor?

Bakın, Açık konuşayım: bu tarz hatalar her yazılımda çıkabiliyor. Microsoft’ta da oluyor, açık kaynak tarafta da (evet, doğru duydunuz). Mesele hata değil; asıl mesele, iş patladığında nasıl toparladığınız. Bu olayda Microsoft’un refleksi fena değildi, çünkü aspnetcore issue #66335 açıldıktan kısa süre sonra sorun ayıklandı. OOB güncelleme de çıktı.

Bence, Yine de içimde bir ukde kaldı. Bu bug.NET 10.0.0’dan beri vardı, yanı GA çıktığı günden beri oradaydı; altı küsur sürüm boyunca kimse yakalayamadı. HMAC doğrulaması kâğıt üstünde var gibi dururken pratikte çalışmayan bir kod production’da aylarca yaşamış öldü. İşte tam burada kriptografik kod için yazılan birim testlerinin neden bu kadar önemli olduğunu tekrar görüyorsunuz.

Bence doğru tarafa gidiliyor, evet. Microsoft’un şeffaf davranması, CVE yayımlaması. OOB güncelleme çıkarması gayet yerinde; ama managed encryptor katmanında daha sert integration test’ler hâlâ eksik dürüyor, hatta ben olsam bunun yanına biraz fuzzing de koyarım (çünkü bazen düzenli testler gözden kaçırıyor). Sız ne dersiniz?

Ha, bunu söylemeden geçmeyeyim..NET 11 Preview sürümlerini takip edenler için küçük bir not var; .NET 11 Preview 3: Gelen Yenilikler ve Sahadan Notlar yazımda anlattığım değişikliklerin içinde Data Protection tarafında da iyileştirmeler bulunuyor ve açıkçası.NET 11’de bu tip bir sorunun tekrar etme ihtimali daha düşük görünüyor.

Pratik Aksiyon Planı

Neyse, lafı uzatmadan gidelim: önce envanteri çıkarın, çünkü ortada ne var bilmiyorsanız sonraki adım biraz kör dövüşüne dönüyor. Hangi uygulama.NET 10 kullanıyor, hangisinde Data Protection açık, hangisi sadece kenardan bakıyor; bunları netleştirin (buna dikkat edin)

Envanter çıkarın: Hangi uygulamalarınız.NET 10 kullanıyor? Hangilerinde Data Protection aktif?
Sürüm kontrolü: dotnet --info çalıştırın. 10.0.7’nın altındaysanız etkilenisiniz. (bence en önemlisi)
Güncelleme: SDK veya en azından NuGet paketini 10.0.7’ye çekin.
Test: Decrypt işlemlerinin düzgün çalıştığını doğrulayın. Bilhassa de 10.0.6 döneminde üretilen şifreli verilerin çözülebildiğinden emin olun. (bence en önemlisi)
Deploy: Staging’de test ettikten sonra production’a alın. — bunu es geçmeyin
Monitör: İlk 24 saat boyunca uygulama loglarında Data Protection ile ilgili exception’ları takip edin.

Sürüm tarafında da iş aslında basit, ama küçük bir detay var: dotnet --info çıktısına bakıp geçmeyin, gerçekten hangi SDK’nın devreye girdiğini anlayın; yoksa “bende sorun yoktu” deyip sonra gece yarısı loglara dalarsınız.

Evet. Bitti gibi görünüyor ama değil; önce test etmeden production’a çıkmayın, özellikle de 10.0.6 döneminde oluşmuş şifreli veriler varsa, onların çözülüp çözülmediğini tek tek görün. Sonra staging’de deneyin, ardından canlıya alın ve ilk 24 saatte exception avına çıkın.

Ciddi bir iş bu. Ama çözümü de göz korkutmuyor; ertelemeyin yeter.

Sıkça Sorulan Sorular

CVE-2026-40372 ne, ve uygulamam için ne kadar tehlikeli?

Bu zafiyet, aslında ASP.NET Core Data Protection’daki HMAC doğrulamasının hatalı çalışmasından kaynaklanıyor. Yanı saldırgan şifreli veriyi manipüle ederek yetki yükseltme (elevation of privilege) yapabiliyor — itiraf edeyim, beklentimin üstündeydi —. Bence ciddiye alınması gereken bir açık — eğer.NET 10 kullanıyorsanız. Kullanıcı oturumu, cookie veya anti-forgery token gibi işlemler yapıyorsanız, hemen ilgilenin (ciddiyim)

.NET 9 veya.NET 8 kullananlar da etkileniyor mu?

Bakın, Hayır. Zafiyet sadece Microsoft.AspNetCore.DataProtection paketinin 10.0.0 ile 10.0.6 arasındaki sürümlerini etkiliyor..NET 9 ve öncesinde farklı bir managed encryptor implementasyonu kullanılıyor, yanı o tarafta sorun yok.

Güncelleme yaparsam mevcut oturumlar düşer mi?

Hayır, mevcut Data Protection key ring’ınız geçerliliğini koruyor. Üstelik tecrübeme göre bu tür güncellemeler genellikle oturumları etkilemiyor — hatta 10.0.6’da yaşanan decrypt hataları da 10.0.7 ile düzeliyor. Yanı güncelleme sonrası daha az sorunla karşılaşırsınız, daha fazla değil.

Out-of-band (OOB) güncelleme ne demek?

İnanın, Microsoft normalde güvenlik yamalarını ayın ikinci Salı günü yayınlıyor, hani bilinen Patch Tuesday takvimi. Ama açıkçası bazen bu takvim beklenemeyecek kadar kritik bir zafiyet çıkıyor. İşte o zaman Microsoft takvimi es geçip acil güncelleme çıkarıyor — buna out-of-band deniyor. OOB görüyorsanız, “ciddi bir şeyler var, hemen güncelle” diye okuyun.

Container ortamında ne yapmalıyım?

Base image’ınızı mcr.microsoft.com/dotnet/aspnet:10.0.7 olarak güncelleyin, image’ları rebuild edip deploy edin. Rolling deployment yapıyorsanız tüm pod’ların yeni image ile ayağa kalktığından emin olun — yarım yamalak bir geçiş istemezsiniz.

Kaynaklar ve İleri Okuma

.NET 10.0.7 Out-of-Band Security Update —.NET Blog

aspnetcore issue #66335 — Decryption Regression Report

ASP.NET Core Data Protection — Microsoft Learn Resmî Dokümantasyonu (ki bu çoğu kişinin gözünden kaçıyor)

İçeriği paylaş:

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102