WordPress Güvenlik Açığına Yönelik Yama Kurulumu Sırasında Siteler Son Bir Kez Daha Risk Altında Kalabilir

WordPress Güvenlik Açığına Yönelik Yama Kurulumu Sırasında Siteler Son Bir Kez Daha Risk Altında Kalabilir

Picus Security araştırmacısı Umut Bayram’a göre, bazı WordPress siteleri aktif olarak istismar edilen bir güvenlik açığına yönelik yamayı kurarken bile saldırıya uğrayabilir.

Yamayı yükleyen güncelleme, dosyalarını sitenin eski, yamalanmamış kodunu kullanarak açmaya devam ediyor. Bu durum, doğru anda saldıran bir saldırganın sunucuda kod çalıştırmasına olanak tanıyor. Araştırmacı, güncelleme yapmadan önce sitenin wp-content/upgrade klasörüne web erişimini engellemeyi tavsiye ediyor.

CVE-2026-119977 olarak izlenen bu güvenlik açığı, WordPress 4.7’den 7.1.3’e kadar olan sürümleri etkiliyor. Tam bir paket kullanan çekirdek güncellemesi 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 yükleyicisini içerir ve web sunucusu genellikle bu kopyaya erişebilir.

Hesabı olmayan bir saldırgan, klasörün adını belirleyebilir ve WordPress kopyayı silmeden önce yükleyiciye erişirse, sunucuda kod çalıştırabilir. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), bu güvenlik açığını bu hafta başında bilinen istismar edilen güvenlik açıkları kataloğuna ekledi.

WordPress, yamayı geçen hafta 7.1.4 sürümünde ve 4.7’ye kadar olan eski dallar için eşleşen güncellemelerde yayınladı. Tüm bu güncellemeler, güvenlik duyurusunda listelenmiştir.

Yama, geçici klasöre rastgele bir ad verir. Ancak yamayı yükleyen güncelleme, dosyalarını sitede zaten bulunan eski kodu kullanarak açar. WordPress’in güncelleyici kodu da bunu göstermektedir. 5.9 veya sonraki sürümleri çalıştıran sitelerde, bu eski kod klasörü indirilen dosyanın adıyla adlandırır, bu nedenle ad son bir kez tahmin edilebilir.

Yamadan önce, bir saldırgan yükleyiciyi kullanarak geçici kopyaya yeni bir yapılandırma dosyası olan wp-config.php yazabilirdi. Güncelleme daha sonra sitenin gerçek dosyasını bu dosya ile üzerine yazardı. Bunu durduran yamanın bir kısmı, WordPress dosyaları yeni kodu kullanarak yerine kopyaladığı için, yamayı yükleyen güncelleme sırasında zaten çalışır.

Bayram, teknik yazısında, bu güncelleme sırasında pencereyi yakalayan bir saldırganın, geçici WordPress kopyasını kendi veritabanıyla kurabileceğini, giriş yapabileceğini ve kopya silinmeden önce web sunucusunun izinleriyle PHP kodu çalıştırabileceğini belirtiyor. Buradan itibaren saldırgan, canlı WordPress sitesindeki dosyaları okuyabilir veya yazabilir.

Güncelleme Sırasında Kimler Risk Altında?

Araştırmacı, her güncellemenin yükleyiciyi açığa çıkarmadığını belirtiyor. Tam paketler her zaman yükleyici dosyalarını içerir. Belirli bir başlangıç sürümü için oluşturulmuş daha küçük bir kısmi paket, yalnızca bu dosyaları içeriyorsa bir siteyi açığa çıkarır.

Otomatik arka plan güncellemelerine izin veren sitelerde, WordPress yamayı aynı güncelleyici ve aynı adımlarla otomatik olarak yükler.

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

4.4’ten 5.8’e kadar olan sürümlerde, eski kod klasörün adına rastgele karakterler ekler. Bu, site adı başka bir şekilde, örneğin bir hata mesajında sızdırmadığı sürece adı gizler, diyor araştırmacı.

7.1.4 veya bir dal yaması yüklendikten sonra, sonraki güncellemeler rastgele bir klasör adı kullanır ve geçici kopyadaki bir wp-config.php dosyası asla gerçek dosyanın üzerine kopyalanmaz.

Güncelleme Öncesi Yapılması Gerekenler

Araştırmacının ilk tavsiyesi, web sunucusunun wp-content/upgrade klasörünü hiç sunmasını engellemektir. WordPress bu klasörle doğrudan disk üzerinde çalıştığı için, web erişimini engellemek güncellemeleri bozmaz, diyor.

1. Web sunucusu yapılandırmasında klasörü engelleyin. Nginx’te, location ^~ /wp-content/upgrade/ { deny all; } ekleyin. Apache’de, sanal ana bilgisayar yapılandırmasındaki o klasör için bir <Directory> bloğunun içine Require all denied ekleyin.
2. Yalnızca .htaccess dosyasını düzenleyebiliyorsanız, WordPress kök dizinindeki .htaccess dosyasına, WordPress yeniden yazma kurallarının üzerine RedirectMatch 403 ^/wp-content/upgrade/ ekleyin.
3. wp-content/upgrade içine bir .htaccess dosyası koymayın. Eski güncelleyici, bir güncellemeyi açmadan önce o klasördeki her şeyi siler, bu nedenle dosya gerektiğinde ortadan kalkacaktır.
4. /wp-content/upgrade/ adresine yapılan bir isteğin 403 hatası döndürdüğünü onaylayın.
5. 7.1.4’e veya dalınız için düzeltilmiş sürüme güncelleyin.

Diğer güvenli yol ise, web kök dizininin dışında, web sunucusunun sunmadığı bir klasörde manuel bir güncelleme yapmaktır. Site dosyalarını ve veritabanını yedekleyin, yeni sürümü web sunucusunun sunmadığı bir klasöre açın, wp-config.php veya wp-content’e dokunmadan çekirdek dosyaları yerine kopyalayın ve ardından WordPress veritabanı güncellemesini çalıştırın. Bu şekilde, web’in erişebileceği bir klasörde asla geçici bir yükleyici oluşturulmaz.

WP-CLI’nin wp core update komutu bir alternatif değildir, çü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üncellemeleri almıyor, bu nedenle onlar için bir düzeltme bulunmuyor. Araştırmacı, güvenlik açığının 2008’de yayınlanan WordPress 2.7’ye kadar uzandığını ve bu sitelerin desteklenen bir sürüme geçmesi gerektiğini belirtiyor.

Saldırılar ve Kontrol Edilmesi Gerekenler

CISA’nın bu hafta başındaki katalog eklemesi, aktif istismar kanıtlarına dayanıyordu, ancak ajans saldırıları açıklamadı.

CVE tanımlayıcısını atayan WordPress güvenlik şirketi Wordfence, yayınlandığı gün güvenlik açığı için bir güvenlik duvarı kuralı dağıttıktan dokuz dakika sonra saldırı girişimlerinin başladığını gördü. En yoğun iki kaynak, yaklaşık 14.5 saat boyunca küçük site gruplarını kontrol etmeye devam etti. Şirket, saldırı analizinde bunun, bir sitenin güncellendiği anı yakalama girişimleriyle uyumlu olduğunu belirtiyor.

CVE kaydındaki güvenlik açığı için puanı CVSS ölçeğinde 10 üzerinden 8.1’dir. Laboratuvar testlerinde, pencere yalnızca saniyeler sürdü. WordPress’in kendi duyurusu güvenlik açığını düşük olarak derecelendiriyor.

Yazarları tarafından güvenlik açığı için bir istismar olarak tanımlanan kod, bu hafta başından beri genel GitHub depolarında ortaya çıktı. Bunlardan biri, kodunun tam paket güncellemeleri sırasında hala tahmin edilebilir bir klasör kullanan sitelerde de çalıştığını belirtiyor. Kodun çalışıp çalışmadığı henüz belirlenmedi.

Yayınlandıktan sonra etkilenen bir sürümde kalan siteler için Wordfence şunları kontrol etmeyi öneriyor:

• wp-content/upgrade altındaki PHP dosyalarına beklenmedik istekler
• kimsenin tanımadığı yönetici hesapları
• kimsenin yüklemediği eklentiler
• wp-content/upgrade içinde kimsenin koymadığı PHP dosyaları

Güncelleme

Bayram, 6 Kasım’da The Hacker News’e yaptığı açıklamada, kısmi bir güncellemenin açığa çıkıp çıkmadığının, o belirli paketin ne içerdiğine bağlı olduğunu söyledi. Kısmi bir paket, yalnızca iki sürüm arasında değişen dosyaları içerir. Eğer bunlar yükleyici dosyalarını içermiyorsa, geçici kopya bir WordPress kurulumu olarak çalışamaz ve yükleyici asla erişilebilir hale gelmez.

Bir site, bir kısmi paket mevcut olduğunda bile her zaman kısmi bir paket almaz. Sitenin çekirdek dosyaları resmi sağlama toplamlarıyla eşleşmiyorsa veya güncelleme yeniden yükleme ise WordPress tam bir pakete geri döner.

Araştırmacı, belirleyici faktörün “kısmiye karşı tam değil. Sitede zaten yüklü olan güncelleyicinin düzeltilip düzeltilmediği” olduğunu belirtti.