Eylül 2026 Windows Server güncellemeleri RDS'yi bozuyor, geri alma ise 9.8 şiddetinde bir açığı yeniden devreye sokuyor

Ne bozuldu

dev.to'da yayımlanan bir yazıya göre Microsoft'un 8 Eylül 2026'da yayımladığı kümülatif güncellemeler — Windows Server 2019 için KB5122876, Windows Server 2022 için KB5122882 ve Windows Server 2025 için KB5122871 — normal şekilde kuruluyor ve Remote Desktop Services birkaç saat boyunca sorunsuz çalışıyor. Sorun, kullanıcı oturum kapatma dalgasının ilk basamağıyla ortaya çıkıyor: mevcut oturumlar düzgün şekilde sonlanmıyor, yeni bağlantı girişimleri askıda kalıyor ve MMC, RDS Licensing Diagnoser ve Dosya Gezgini gibi ilgili araçlar da yanıt vermemeye başlıyor. Bazı yöneticiler, ana bilgisayarları kurtarmak için sert sıfırlama yapmak zorunda kaldıklarını bildirdi.

Microsoft'un genel belgeleri sorunu kabul ediyor ve tek bir geçici çözüm sunuyor: etkilenen sanal makineyi durdurup yeniden başlatmak. Windows Server 2025 için yayımlanan sürüm sağlığı kaydı, sorunun 11 Eylül itibarıyla hafilletildiğini kalıcı çözümün ise gelecekteki bir Windows güncellemesinde geleceğini belirtiyor. Dev.to yazısının yayımlandığı tarih itibarıyla, o genel sayfada listelenmiş bir Grup İlkesi nesnesi veya Known Issue Rollback paketi bulunmuyor.

Geri alma ödünleşimi

Aynı Eylül kümülatif döngüsü, CVSS 9.8 olarak derecelendirilmiş, Windows RDS'deki use-after-free türünde bir uzaktan kod çalıştırma açığı olan CVE-2026-69525 düzeltmesini de getirdi. Dev.to yazısı bu açığın kimlik doğrulaması gerektirmediğini, kullanıcı etkileşimi olmadan istismar edilebildiğini ve 2012'den 2025'e kadar Windows Server sürümleri ile çeşitli istemci sürümlerini etkilediğini belirtiyor. Etkilenen yapıların, üç sunucu sürümünün tamamında Eylül'de yamalanmış sürümlerle örtüştüğü bildiriliyor — Server 2019 için 17763.9245, Server 2022 için 20348.5622 ve Server 2025 için 26100.33438.

Bu durum, güvenli bir dinlenme noktası olmayan üçlü bir çıkmaza yol açıyor. Güncellemeyi kurulu tutun ve oturumları süresiz olarak askıda bırakabilen bir kesintiye katlanın. Yamalı ama bozuk durumda kalın: CVE'ye karşı hâlâ korumalısınız ama servis fiilen çalışmıyor. Ya da kullanılabilirliği geri kazanmak için güncellemeyi kaldırın — ve yapı gereği, RDP üzerinden erişilebilir olabilecek altyapıda, ana bilgisayarı 9.8 şiddetindeki bir açığa karşı savunmasız duruma geri döndürün. Dev.to analizinde vurgulandığı gibi, açık varlığı, doğrulanmış istismar ve gerçek internet erişimi birbirinden ayrı şeylerdir; ancak geri alma kararı kaçınılmazdır.

Kök neden henüz doğrulanmış değil

Microsoft hata modunu ve yeniden başlatma geçici çözümünü doğruladı, ancak temeldeki mekanizmayı doğrulamadı. Dolaşımdaki işleyen teori, Reddit'te yayımlanıp BleepingComputer tarafından aktarılan, bir yöneticinin Server 2022 ana bilgisayarı üzerindeki çekirdek düzeyindeki hata ayıklamasından geliyor: servis, görünüşe göre bir zaman aşımından yoksun şekilde RDPSERVERBASE!WDLIB_Close içinde askıda kalıyor ve bu durum RDP'yi LSM'ye (Local Session Managers) karşı kilitliyor. Sonraki bazı uygulayıcı yazıları, askıda kalmayı o kod yolunu denetleyen bir iç özellik bayrağına bağlıyor; ancak dev.to yazısı bunu, zaten doğrulanmamış kanıtların üzerine yığılmış daha zayıf bir kanıt olarak sınıflandırıyor.

Pratik uyarı şu: olay müdahale planları, izleme eşikleri ya da sorun sonrası değerlendirme dili bir kilitlenme teorisi etrafında kurulursa ve Microsoft'un nihai kök neden analizi başka bir şeyi işaret ederse, o süreç makul bir tahmine dayanmış olur. Mimari sorun — kullanılabilirliği bozan, kurtarmanın ise bir güvenlik düzeltmesini tersine çevirdiği bir yama — nihai RCA hangi mekanizmayı işaret ederse işaret etsin geçerliliğini koruyor.

Ayrıca dikkat çekmeye değer bir bilgi asimetrisi var. Dev.to yazısı, uygulayıcıların Grup İlkesi üzerinden bir Known Issue Rollback'in var olduğunu, ancak bunun yalnızca Microsoft'un M365-admin Message Center içinde belgelendiğini bildirdiğini aktarıyor; M365 kiracı ilişkisi olmayan birçok Windows Server işletmesinin hiç göremeyeceği bir kanal bu. Aynı arızayı ve aynı açığı yöneten iki yönetici, bu nedenle farklı risk azaltma menüleriyle çalışıyor olabilir.

Neden önemli

Bu olay, yama geri alma riskinin somut bir örneği: düzeltme ile o düzeltmenin hata modundan kurtarma aynı karar için yarıştığında, otomatik olarak güvenli bir geri çekilme yolu kalmaz. Kötü bir güncellemeyi çekmek refleksi haline getirmiş ekiplerin, önce kaldırmanın hangi CVE'leri yeniden devreye soktuğunu ve ana bilgisayar yeniden korumasızkalırken hangi telafi edici denetimlerin — ağ düzeyinde RDP erişim kısıtlamaları, session broker yalıtımı — araya girebileceğini kontrol eden bir geri alma politikasına ihtiyacı var. Bu olay ayrıca satıcı iletişim kanallarının neden önemli olduğunu gösteriyor: risk azaltma rehberliği genel bir sürüm sağlığı sayfası ile erişim kısıtlı bir yönetim merkezi arasında bölündüğünde, olay müdahalesinin kalitesi, müdahale eden yöneticinin hangi kanala erişimi olduğuna bağlı olabilir. Microsoft söz verdiği kalıcı düzeltmeyi gönderene kadar, etkilenen her kuruluş, çalışma süresi ile uzaktan erişim altyapısındaki kimlik doğrulamasız bir RCE arasında kendi kararını vermek durumunda kalıyor.