WordPress’in çekirdek güncelleme mekanizmasındaki bir yarış durumu, yama yüklenirken siteleri kısa bir süreliğine saldırıya açık bırakabiliyor. Etkilenen sürümler 4.7 ile 7.1.3 arasındaki tüm ana dalları kapsıyor; WordPress 7.1.4 ve eski seriler için yayımlanan düzeltme sürümleriyle açık kapatıldı. Ancak güvenlik araştırmacısı Umut Bayram’ın analizine göre, düzeltmeyi kuran güncelleme paketinin kendisi hâlâ eski kodu kullanarak açıldığı için, saldırgan doğru anı yakalarsa sunucuda kod çalıştırabiliyor.

İlgili açık CVE-2026-119977 olarak izleniyor. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı CISA, 3 Kasım 2026’da bu zaafı bilinen ve aktif olarak istismar edilen açıklar kataloğuna ekledi. CVSS puanı 8.1 olan sorun için WordPress’in güvenlik duyurusunda risk seviyesi düşük olarak işaretlendi. NVD kaydı için: https://nvd.nist.gov/vuln/detail/CVE-2026-119977

Teknik sorun, tam paketle yapılan çekirdek güncellemelerinde ortaya çıkıyor. WordPress, yeni sürümü önce web sunucusunun erişebildiği wp-content/upgrade klasörü altındaki geçici bir dizine açıyor, ardından dosyaları canlı siteye kopyalıyor ve son olarak geçici çalışma alanını siliyor. Araştırmaya göre bu sırada dizin adı öngörülebilir kalabiliyor; 5.9 ve sonrası sürümlerde eski güncelleme kodu klasöre indirilen dosyanın adını veriyor. 4.4 ile 5.8 arasındaki sürümlerde ise dizin adına rastgele karakterler ekleniyor, bu da adı yalnızca başka bir yolla sızdırılırsa görünür kılıyor.

Bayram’ın yayımladığı teknik inceleme, saldırganın yönetici hesabına ihtiyaç duymadan bu pencereye sızabileceğini gösteriyor. Saldırgan, geçici kopya üzerinde önce kendi veritabanını kurabiliyor, ardından WordPress’e giriş yapıp web sunucusunun izinleriyle PHP kodu çalıştırabiliyor. Bu aşamadan sonra canlı sitedeki dosyaları okuma ya da değiştirme yetkisi elde edilebiliyor. Önceki sürümlerde saldırı zinciri daha da ileri giderek wp-config.php dosyasının canlı kurulumun üzerine yazılmasına kadar uzanabiliyordu; yeni düzeltme bu kısmı değiştiriyor, ancak güncelleme yüklenirken açılan kısa pencere tamamen ortadan kalkmış değil.

WordPress çekirdek güncellemeyi tam paketle yaptığında, yükleyici dosyaları da geçici klasörün içinde yer alıyor. Daha küçük bir yama paketi ise yalnızca belirli bir başlangıç sürümü için hazırlanıyor ve bu yüzden içinde yükleyici dosyalarının olup olmaması belirleyici hale geliyor. Otomatik arka plan güncellemesi açık sitelerde de süreç aynı yükseltici üzerinden işliyor. Yapılan testlerde WordPress.org’un güncelleme servisi, 7.1.3’ten 7.1.4’e geçiş gibi aynı dal içindeki güncellemelerde kısmi paket sundu; 7.0.7’den 7.1.4’e çıkış gibi daha eski bir daldan geçişlerde ise yalnızca tam paket döndürdü.

Güvenlik araştırmacısına göre saldırı penceresi, paketin türünden çok o paketin içeriğine bağlı. Bir kısmi paket, iki sürüm arasındaki değişen dosyaları içeriyor; bu dosyalar arasında kurulum dosyaları yoksa geçici kopya WordPress kurulumu gibi davranmıyor ve yükleyici erişilebilir hale gelmiyor. Üstelik site, bir kısmi paket mevcut olsa bile her zaman onu almıyor. Çekirdek dosyalar resmi sağlama toplamlarıyla uyuşmuyorsa ya da işlem bir yeniden kurulum olarak ele alınıyorsa WordPress tam pakete dönüyor.

Bayram, en güvenli adımın wp-content/upgrade klasörünü web erişimine tamamen kapatmak olduğunu söylüyor. WordPress güncellemeleri doğrudan disk üzerinde yaptığı için bu engel, yükseltme işlemini bozmayacak. Nginx kullananlar için önerilen kural location ^~ /wp-content/upgrade/ { deny all; } şeklinde. Apache tarafında ise sanal ana makine yapılandırmasındaki ilgili <directory> bloğuna Require all denied eklenmesi gerekiyor.

Yalnızca .htaccess düzenlenebiliyorsa, WordPress kök dizinindeki .htaccess dosyasına, yeniden yazma kurallarının üstüne RedirectMatch 403 ^/wp-content/upgrade/ satırı eklenmesi öneriliyor. Araştırmacı, wp-content/upgrade klasörünün içine ayrı bir .htaccess koymanın doğru yöntem olmadığını da belirtiyor; eski güncelleyici klasördeki her şeyi yeni paketi açmadan önce sildiği için o dosya ihtiyaç anında ortada kalmıyor. Sonrasında /wp-content/upgrade/ isteğinin 403 döndürdüğünün doğrulanması ve 7.1.4 ya da ilgili dal için yayımlanan sabit sürüme geçilmesi gerekiyor.

Bir diğer güvenli yol, web kök dizininin dışında elle güncelleme yapmak. Bu yöntemde site dosyaları ve veritabanı yedekleniyor, yeni sürüm web sunucusunun servis etmediği bir klasöre açılıyor, çekirdek dosyalar wp-config.php ve wp-content alanlarına dokunulmadan yerine kopyalanıyor, ardından WordPress veritabanı güncellemesi çalıştırılıyor. Böylece web erişimine açık bir geçici kurulum hiç oluşmuyor. Buna karşılık wp core update komutu çözüm sayılmıyor; çünkü aynı yükselticiyi kullanıyor ve paketi yine aynı klasöre açıyor.

WordPress 4.6 ve daha eski sürümler artık güvenlik desteği almıyor. Araştırmacı, bu hatanın kökenini WordPress 2.7’ye, yani 2008’de yayımlanan sürüme kadar götürdüğünü belirtiyor. Bu nedenle eski kurulumların desteklenen bir sürüme taşınması gerektiğini söylüyor.

CISA’nın hafta başında kataloğa ekleme kararı, aktif istismar bulgusuna dayanıyordu ancak kurum saldırıların ayrıntısını paylaşmadı. Wordfence ise CVE numarasını veren şirket olarak, koruma kuralını devreye aldıktan yalnızca dokuz dakika sonra saldırı denemeleri gördüğünü açıkladı. En yoğun iki kaynak yaklaşık 14,5 saat boyunca küçük site gruplarını kontrol etmeyi sürdürdü; şirket bunun, bir sitenin güncelleme anını yakalamaya dönük girişimlerle uyumlu olduğunu belirtiyor.

Wordfence’in açık için CVE kaydındaki puanı 8.1. Şirketin laboratuvar testlerinde saldırı penceresi yalnızca saniyeler sürdü. WordPress’in kendi güvenlik duyurusu ise zaafı düşük şiddette sınıflandırıyor. Buna karşın, açık için yazıldığı belirtilen kodlar hafta başından bu yana kamuya açık GitHub depolarında görünmeye başladı. Depolardan biri, kodun tam paket güncellemelerinde hâlâ öngörülebilir klasör adı kullanan sitelerde de çalıştığını iddia ediyor; ancak bunun gerçek koşullarda doğrulandığı söylenmiyor.

Güncelleme sonrasında bırakılan izleri inceleyen Wordfence, savunmacıların özellikle wp-content/upgrade altındaki PHP dosyalarına yönelik beklenmedik istekleri, tanınmayan yönetici hesaplarını, kimsenin yüklemediği eklentileri ve geçici klasörde sonradan beliren PHP dosyalarını kontrol etmesini öneriyor. Araştırmacı Bayram ayrıca 6 Kasım’da yaptığı açıklamada, kısmi bir paketin gerçekten açığa maruz kalıp kalmayacağının o pakette hangi dosyaların bulunduğuna bağlı olduğunu vurguladı. Ona göre belirleyici nokta, paketin kısmi mi tam mı olduğu değil, güncelleme sırasında sitede çalışan yükselticinin yamalı olup olmadığı.

P	S	Ç	P	C	C	P
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

WordPress güncellemesi sırasında açılan boşluk saldırıya izin verebilir

Kaynaklar