WordPress CVE-2026-119977 Saldırıda: Çekirdek Güncellemesi Sırasında Kod Çalıştırma, 7.1.4’e Geçin

Açık nedir? (Upgrade window race condition)

WordPress tam paketle çekirdek güncellemesi yaptığında yeni sürümü önce wp-content/upgrade/ altındaki bir çalışma klasörüne açar, sonra dosyaları canlı kuruluma kopyalar. 7.1.4 öncesinde bu klasörün adı paket dosyasının adından türetiliyordu, yani tahmin edilebilirdi. wp-content klasörü web üzerinden erişilebilir olduğu için güncelleme sürerken o klasördeki dosyalar HTTP ile istenebiliyordu. WordPress'in sürüm notu bunu "güncelleme penceresinde uzaktan kod çalıştırmaya yol açabilen bir zayıflık" olarak tanımlıyor.

Açığın kaydını Wordfence yayımladı. CVSS 3.1 puanı 8.1 (Yüksek); saldırı karmaşıklığı "yüksek" çünkü saldırganın güncelleme anını yakalaması gerekiyor. CISA'nın değerlendirmesinde istismar "aktif", teknik etki "tam" olarak işaretli. Federal kurumlar için son düzeltme tarihi 6 Kasım 2026.

7.1.4 ile gelen değişiklikler şunlar: çalışma klasörünün adına 16 karakterlik rastgele bir ek konuyor, klasöre dizin listelemeyi engelleyen bir index.php yerleştiriliyor ve canlı kuruluma kopyalama sırasında wp-config.php atlanıyor.

Etkilenen ve düzeltilmiş sürümler (Affected and fixed versions)

WordPress ekibi düzeltmeleri güvenlik desteği verilen tüm dallara (4.7'ye kadar) "nezaketen" taşıdığını, ama yalnız en son sürümün etkin olarak desteklendiğini belirtiyor. Eski bir dalda kalan site düzeltmeyi alsa bile 7.1.4'e geçmeyi planlamalı.

Sürüm nasıl kontrol edilir? (Check WordPress version)

WP-CLI varsa:

wp core version --extra --path=/var/www/html

WP-CLI yoksa sürüm dosyasından:

grep '^\$wp_version' /var/www/html/wp-includes/version.php

Docker kullananlar sürümü imaj etiketinden değil, çalışan kapsayıcının içinden okumalı. Sunucuda birden çok site varsa tümünü tek komutla tarayabilirsiniz:

find /home /var/www -name version.php -path '*wp-includes*' 2>/dev/null | while read f; do echo "$f: $(grep -oP "wp_version = '\K[^']+" "$f")"; done

Güncellemeden önce ve sonra (Mitigation)

1. Önce iz toplayın. Güncelleyici wp-content/upgrade/ klasörünü boşaltır. Ele geçirilmeden şüpheleniyorsanız güncellemeden önce bu klasörü arşivleyin, veritabanının ve erişim günlüklerinin kopyasını alın.
2. Klasöre web erişimini kapatın. nginx'te location ^~ /wp-content/upgrade/ { deny all; }, Apache'de sunucu yapılandırmasında o dizin için Require all denied. Klasörün içine .htaccess koymayın; eski güncelleyici onu siler.
3. 7.1.4'e ya da dalınızın düzeltilmiş sürümüne geçin. Yönetim panelinde Güncellemeler sayfasından "Şimdi güncelle" ya da wp core update.
4. Dosya bütünlüğünü doğrulayın: wp core verify-checksums --include-root. Bu komut wp-config.php ve wp-content klasörünü kapsamaz; onlara ayrıca bakın.
5. Çok sayıda site yöneten ekipler çekirdeği panelden değil, doğrulanmış paketten dağıtmayı ve site içi güncelleyiciyi DISALLOW_FILE_MODS ile kapatmayı değerlendirebilir.

Bir uyarı: bazı güvenlik ekipleri 7.1.3'ten 7.1.4'e geçişin de eski kodla açılan son bir güncelleme penceresinden geçtiğini not ediyor. Bu WordPress'in resmî açıklaması değil, ama 2. adımdaki web erişimi engelinin güncellemeden önce konması bu yüzden önemli.

Ele geçirilme izleri (Indicators)

Yayın tarihi itibarıyla kamuya açık bir saldırı raporu ya da gösterge listesi yok. Bakılacak yerler:

• Erişim günlüklerinde /wp-content/upgrade/ altına yapılan istekler, güncelleme saatlerine yakın setup-config.php ya da install.php isteklerine dönen 2xx yanıtlar.
• wp-content/upgrade/ içinde tanımadığınız .php dosyaları ya da bir wp-config.php.
• Yeni yönetici hesapları, değişmiş siteurl, tanımadığınız zamanlanmış görevler, mu-plugins altında yeni dosyalar, uploads altında PHP dosyaları.

grep -E '/wp-content/upgrade/' /var/log/nginx/access.log* | tail -50

İz bulunursa: yönetici şifrelerini sıfırlayın, güvenlik anahtarlarını yenileyin (wp config shuffle-salts) ve siteyi bilinen temiz dosyalardan yeniden kurun.

7.1.4'teki diğer düzeltmeler

Aynı sürüm, güncelleme açığının yanında çok sayıda depolanmış XSS (stored XSS) açığını kapatıyor: blok işaretlemesi, Interactivity API, Özelleştirici seçmeli yenileme, Kategoriler, Oynatma listesi, Görsel ve yorum sayfalama blokları, gizlilik veri silme talepleri ve özel hazırlanmış kullanıcı adları. Ayrıca yayımlanmamış Özelleştirici değişiklik setlerinin oturum açmamış kullanıcılarca bulunabilmesi ve düzenleme yetkisi olmayan kullanıcıların yazı notlarını okuyabilmesi giderildi. Sürüm, eMudhra iptali nedeniyle paketle gelen kök sertifikaları da güncelliyor; bu konuyu eMudhra yazısında anlatmıştık.

WordPress dışında PHP çalıştıran sunucularda da aynı hafta önemli açıklar var: PHP'nin kendisindeki PHP2Shell ve Linux çekirdeğindeki Fragnesia. Alesta WEB'in barındırma tarafındaki önerisi, üçünün sürüm kontrolünü aynı bakım turunda yapmak.

Sık sorulan sorular

Otomatik güncellemesi açık sitelerde bir şey yapmam gerekir mi?

Arka plan güncellemesini destekleyen siteler 7.1.4'ü kendiliğinden alıyor. Yine de sürümü kontrol edin; dosya izinleri ya da AUTOMATIC_UPDATER_DISABLED ayarı yüzünden güncelleme yapılmamış olabilir.

Eklenti güncellemesi de bu açıktan etkilenir mi?

CVE kaydı tam paketle çekirdek güncellemesini ve ilgili güncelleyici sınıflarını anıyor. Eklenti güncellemeleri kayıtta ayrıca belirtilmemiş; 7.1.4'e geçmek her durumda güncelleyici kodunu düzeltir.

Güncelleme sırasında siteyi bakım moduna almak yeterli mi?

Hayır. Bakım modu ziyaretçiye gösterilen sayfayı değiştirir, wp-content altındaki dosyalara doğrudan erişimi engellemez. Sunucu düzeyinde erişim kuralı gerekir.

İlgili sayfalar: Web hosting · Web yazılım hizmetleri · PHP2Shell · İletişim

Kapak fotoğrafı: Alabama Extension / Wikimedia Commons (CC0)