WordPress Açığı İçin Yama Yüklemek Siteleri Son kez Maruz Bırakabilir.

Birçok WordPress sitesi, aktif olarak sömürülen bir açığı gidermek için yama yüklerken saldırıya uğrayabilir; açığı bulan Picus Security araştırmacısı Umut Bayram’a göre.

Yamayı yükleyen güncelleme, dosyaları sitenin eski, yamasız kodunu kullanarak açtığı için doğru anda müdahale eden bir saldırgan sunucuda kod çalıştırabilir. Araştırmacı, güncellemeden önce sitenin wp-content/upgrade klasörüne web erişiminin engellenmesini öneriyor.

CVE-2026-119977 olarak takip edilen açık, WordPress 4.7 ile 7.1.3 arasındaki sürümleri etkiliyor. Tam paket kullanan bir çekirdek güncelleme sırasında WordPress, yeni sürümün bir kopyasını wp-content/upgrade içindeki geçici bir klasöre açar. Bu kopya WordPress kurucusunu içerir ve web sunucusu genellikle buna erişebilir.

Klasörün adını belirleyebilen ve WordPress kopyayı silmeden önce kurucuya erişebilen, hesabı olmayan bir saldırgan sunucuda kod çalıştırma sonucuyla karşılaşabilir. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), açığı bu hafta başında bilinen sömürülen açıklar kataloğuna ekledi.

WordPress, yama geçen hafta 7.1.4 sürümünde ve 4.7’ye kadar uzanan eski dallar için eş güncellemelerle yayımladı; tümü güvenlik uyarısında listeleniyor.

Yama, geçici klasöre rastgele bir ad verir. Ancak yamayı yükleyen güncelleme, WordPress’in güncelleyici kodunun da gösterdiği gibi dosyaları sitenin zaten mevcut olan eski kodunu kullanarak açar. 5.9 veya daha yeni sürümleri çalıştıran sitelerde bu eski kod, klasörü indirilen dosyanın adına göre adlandırır, böylece ad son kez tahmin edilebilir.

Yamadan önce bir saldırgan, kurucuyu kullanarak yeni bir yapılandırma dosyası olan wp-config.php’yi geçici kopyaya yazabilir. Güncelleme ardından sitenin gerçek dosyasını bu dosyayla değiştirirdi. Yamayı engelleyen kısım, WordPress dosyaları yerleştirirken yeni kodu kullandığı için zaten yamayı yükleyen güncelleme sırasında çalışıyor.

Güvenlik açığını bu güncelleme sırasında yakalayan bir saldırgan, WordPress’in geçici kopyasını kendi veritabanıyla kurabilir, buna giriş yapabilir ve kopya silinmeden önce web sunucusunun izinleriyle PHP kodu çalıştırabilir; bu, Bayram’ın teknik yazısında belirttiği gibi. Buradan saldırgan, canlı WordPress sitesindeki dosyaları okuyabilir veya yazabilir.

Güncelleme Sırasında Kimler Maruz Kalır

Her güncelleme kurulumcu programı maruz bırakmaz; araştırmacıya göre tam paketler her zaman kurulumcu dosyalarını içerir. Belirli bir başlangıç sürümü için hazırlanan daha küçük bir kısmi paket, ancak içinde bu dosyaları rastgele içeriyorsa bir siteyi maruz bırakır.

Otomatik arka plan güncellemelerine izin veren sitelerde WordPress, aynı güncelleyici ve aynı adımlar aracılığıyla düzeltmeyi otomatik olarak kurar.

The Hacker News, bugün WordPress.org’un güncelleme hizmetini birkaç sürüm için inceledi. Bir dal içindeki güncellemeler için, örneğin 7.1.3’ten 7.1.4’e, otomatik güncellemeler için de dahil olmak üzere kısmi bir paket sundu. Daha eski bir daldan, örneğin 7.0.7’den 7.1.4’e geçiş için yalnızca tam paketler sundu.

4.4 ile 5.8 arasında eski kod, klasör adına rastgele karakterler ekler. Bu, sitenin adı başka bir yolla, örneğin bir hata mesajında sızdırması dışında adı gizler; araştırmacıya göre.

7.1.4 veya bir dal düzeltmesi kurulduktan sonra, sonraki güncellemeler rastgele bir klasör adı kullanır ve geçici kopyadaki wp-config.php dosyası asıl olanın üzerine kopyalanmaz.

Güncellemeden Önce Ne Yapılmalı

Araştırmacının ilk önerisi, web sunucusunun wp-content/upgrade klasörünü hiç sunmasını engellemektir. WordPress bu klasörle doğrudan disk üzerinde çalışır, bu nedenle web erişimini engellemenin güncellemeleri bozmadığını belirtiyor.

1. Klasörü web sunucusu yapılandırmasında engelleyin. Nginx’te, location ^~ /wp-content/upgrade/ { deny all; } satırını ekleyin. Apache’de ise sanal konak yapılandırmasında bu klasör için bir <Directory> bloğu içine Require all denied satırını ekleyin.
2. Sadece .htaccess dosyasını düzenleyebiliyorsanız, WordPress kökündeki .htaccess dosyasına, WordPress yeniden yazma kurallarının üzerine RedirectMatch 403 ^/wp-content/upgrade/ satırını ekleyin.
3. wp-content/upgrade klasörünün içine .htaccess dosyası koymayın. Eski güncelleyici, bir güncellemeyi açmadan önce bu klasördeki her şeyi siler; bu nedenle dosya gerektiği anda ortadan kalkar.
4. /wp-content/upgrade/’ya yönelik bir isteğin 403 hatası döndüğünü doğrulayın.
5. 7.1.4 sürümüne ya da dalınız için düzeltilmiş sürüme güncelleyin.

Sitenin diğer güvenli yolu, web kökü dışında, sunucunun yaydığı klasörde manuel bir güncelleme yapmak. Site dosyaları ve veritabanı yedeklenmeli, yeni sürüm web sunucusunun yaymadığı bir klasöre açılmalı, wp-config.php veya wp-content üzerinde değişiklik yapılmadan çekirdek dosyalar yerine yerleştirilmeli ve ardından WordPress veritabanı güncellemesi çalıştırılmalı. Bu şekilde, web’in erişebileceği bir klasörde asla geçici bir kurulumcu oluşturulmaz.

WP-CLI’nin wp core update komutu bunun yerine geçmez, çünkü aynı güncelleyiciyi çalıştırır ve paketi aynı klasöre açar.

WordPress 4.6 ve önceki sürümler artık güvenlik güncellemesi almıyor, dolayısıyla onlar için bir düzeltme yok. Araştırmacı, hatanın 2008’de yayılan WordPress 2.7’ye kadar uzandığını ve bu sitelerin desteklenen bir sürüme geçmesi gerektiğini söylüyor.

Saldırılar ve Neye Bakılmalı

CISA’nın bu hafta sonu yaptığı katalog ekleme, aktif sömürü kanıtlarına dayanıyordu ancak ajans saldırıları betimlemedi.

CVE tanımlayıcısını atan WordPress güvenlik şirketi Wordfence, sürüm gününde hataya yönelik bir güvenlik duvarı kuralı yaydıktan dokuz dakika sonra saldırı girişimlerinin başladığını gördü. Meşgul iki kaynak, yaklaşık 14,5 saat boyunca sitelerin küçük gruplarını kontrol etmeye devam etti; şirketin saldırı analizine göre bu, bir sitenin güncellendiği anı yakalama girişimleriyle örtüşüyor.

Hata, CVE kaydındaki puanı CVSS ölçeğinde 10 üzerinden 8.1. Laboratuvar testlerinde açığın etkisi yalnızca birkaç saniye sürdü. WordPress’in kendi uyarısı hatayı düşük seviyede değerlendiriyor.

Yazarlarının açığa yönelik bir sömürü kodu olarak tanımladığı kodlar, bu haftanın başlarından itibaren halka açık GitHub depolarında görülmeye başlandı. Bunlardan biri, kodun paket güncellemelerinin tamamı sırasında hala öngörülebilir bir klasör kullanan sitelerde de çalışabileceğini belirtiyor. Kodun gerçekten çalışıp çalışmadığı ise henüz kesinleşmedi.

Güncelleme sonrası etkilenmiş sürümde kalan siteler için Wordfence, şunları araştırmayı öneriyor:

• wp-content/upgrade altında beklenmedik biçimde istenen PHP dosyaları
• tanınmayan hesap sahipliğinde yönetici hesapları
• kimse tarafından kurulmayan eklentiler
• wp-content/upgrade içinde kimse tarafından konulmayan PHP dosyaları

Güncelleme

Bayram, 6 Kasım’da The Hacker News’a kısmi bir güncellemenin açığa açık olupunun o özel paketin içeriğine bağlı olduğunu söyledi. Kısmi bir paket, iki sürüm arasında değişen dosyaları yalnızca içerir. Kurulum dosyaları bunların arasında değilse, geçici kopya bir WordPress kurulumu olarak çalışamaz ve kurulumcu asıl erişilebilir hale gelmez.

Bir site, kısmi bir paket mevcut olsa bile her zaman bunu almaz. WordPress, sitenin temel dosyaları resmi özetlerle eşleşmiyorsa veya güncelleme yeniden kurulum ise tam pakete geri döner.

Araştırmacının belirttiği gibi belirleyici faktör, “kısmi ile tam arasındaki fark değil. Yükselticinin situra zaten kurulan sürümün düzeltilip düzeltilmediği.”