WordPress 7.0.2 Acil Sürümü wp2shell RCE Açığını Kapatıyor

WordPress’i yirmi yıldır üretim ortamında koşturmak size güvenlik sürümleri hakkında iki şey öğretir. Sıkıcı olanları çarşamba günü uygularsınız. İlginç olanları ise düştüğü anda uygularsınız, hangi gün olduğu fark etmez. Geçen cuma çıkan 7.0.2 kesinlikle ikinci kategoriye giriyor.

WordPress çekirdeğinde kimlik doğrulama gerektirmeyen uzaktan kod çalıştırma zinciri, eskiden yılda bir görülen türde bir haberdi. Bu ciddiyette bir açık gördüğümüz son olayın üzerinden yıllar geçti. Çekirdek güvenlik ekibi, açığın kamuya duyurulduğu gün eşgüdümlü bir yamayı tamamladı, üç eski dala geriye taşıdı, tüm dağıtım üzerinde otomatik güncellemeyi zorladı ve 7.1 beta takvimini olayın etrafında yeniden düzenledi. Olgun bir yönetişim katmanının baskı altındaki hâli tam olarak budur.

Aşağıda 7.0.2 ile fiilen ne çıktığını, zincirin altında neyin çalıştığını ve bu hafta yönetimimizdeki her WordPress sitesinde koşturacağım denetim adımlarını bulacaksınız. Gece boyunca otomatik güncelleme aldığından emin olduğunuz siteler dâhil.

Fiilen ne yeni

WordPress 7.0.2, 17 Temmuz 2026’da program dışı olarak yayınlandı; John Blackbourn WordPress News blogunda duyurdu. Sürüm yazısı kısa ve harfi harfine okunmayı hak ediyor: biri kritik biri yüksek şiddetli iki açık, ikisi de WordPress HackerOne programı üzerinden sorumlu biçimde bildirildi, ikisi de aktif desteklenen her dalda eşzamanlı yamalandı. 7.0.2 sürüm belgesi yalnızca üç dosyanın değiştirildiğini listeliyor — wp-includes/rest-api/class-wp-rest-server.php, wp-includes/class-wp-query.php ve wp-includes/rest-api.php — ve hiçbir paket revize edilmemiş. Bu, içine güvenlik yaması sıkıştırılmış bir bakım sürümü değil, hedeflenmiş bir yama.

Kritik açık CVE-2026-63030, GHSA-ff9f-jf42-662q olarak takip ediliyor. Uyarı diliyle söylersek “SQL enjeksiyonuyla birleştiğinde Uzaktan Kod Çalıştırmaya yol açan bir REST API toplu-yönlendirme karışıklığı zayıflığı”. Zayıf giriş noktası WP_REST_Server::serve_batch_request_v1(), yani WordPress 5.6’da blok düzenleyicisinin birden çok REST çağrısını tek bir istekte hattan geçirebilmesi için eklenen /wp/v2/batch/v1 uç noktasının arkasındaki işleyici. Assetnote / Searchlight Cyber’dan Adam Kues tarafından bildirildi ve 6.9.0 ile 6.9.4, 7.0.0 ile 7.0.1 aralıklarını etkiliyor.

Yüksek şiddetli açık ise CVE-2026-60137, GHSA-fpp7-x2x2-2mjf — WP_Query içindeki author__not_in parametresinde kolaylaştırılmış bir SQL enjeksiyonu. Parametre dizi yerine dize olarak geldiğinde is_array() arındırma kontrolü atlanıyor ve değer doğrudan NOT IN (...) yan tümcesine akıyor. TF1T, dtro ve haongo’nun ekip olarak bildirdiği açık 6.8’den beri var; 6.8.0-6.8.5, 6.9.0-6.9.4 ve 7.0.0-7.0.1 sürümlerini etkiliyor.

6.9 ve üzerinde iki açık zincirleniyor. Toplu istek uç noktası, kimlik doğrulamasız bir saldırganın yetki kontrollerini atlatarak istek kaçırmasına izin veriyor; author__not_in açığı denetlenebilir bir SQL enjeksiyon noktasına dönüşüyor; enjeksiyon noktası, çekirdeğin ardından çalıştıracağı PHP kodunu yerleştirmeye izin veriyor. Cuma gününden bu yana güvenlik topluluğunda dolaşan wp2shell adı buradan geliyor. Site sahipleri için önemli olan takma ad değil. Önemli olan şu: ne oturum açmak, ne eklenti, ne de yapılandırma değişikliği gerekiyor. Etkilenen bir sürümdeki standart bir WordPress kurulumu, kimliği belirsiz bir HTTP isteğiyle sömürülebilir durumdaydı.

Yamalar desteklenen her dala paralel olarak indi: mevcut ana sürüm için 7.0.2, bir önceki ana sürüm için 6.9.5 (her iki zincir bileşeni), yalnızca güvenlik dalı için 6.8.6 (yalnızca SQL enjeksiyonu, zinciri mümkün kılan toplu uç noktası değişikliği 6.8’de yoktu) ve sürüm günü hâlâ betada olan dal için 7.1 beta2. 7.1 çekirdek sayfası, olayın etrafında beta takviminin yeniden düzenlendiğini doğruluyor: özgün 22 Temmuz Beta 2 tarihi 17 Temmuz’da güvenlik yamalı yeniden basılmış bir Beta 2’ye dönüştü, 29 Temmuz’a ek bir beta eklendi, RC 1 5 Ağustos’ta kaldı ve GA hâlâ 19 Ağustos hedefinde. WordPress.org, etkilenen her sürüm için güncelleme API’si üzerinden zorunlu otomatik güncellemeyi devreye aldı. Kâğıt üzerinde dağıtımın büyük çoğunluğu şimdiden yamalı bir yapıda. Kâğıt üzerinde.

WordPress ve WooCommerce ekipleri için neden önemli

Varsayılan çekirdekte kimlik doğrulama gerektirmeyen uzaktan kod çalıştırma en kötü senaryo kategorisidir. Öne koyabileceğiniz her şeyi atlatır — hiçbir WAF kuralı biçim değiştiren bir toplu istek yükünü güvenilir biçimde eşleştiremez, hiçbir hız sınırı iyi biçimlendirilmiş tek bir isteğe karşı koruma sağlamaz, hiçbir iki adımlı doğrulama anonim bir uç noktanın önünde durmaz. Çalışan yalnızca iki savunma vardır: yamalı sürümde olmak ve bunu kanıtlayabilmek.

Zorunlu otomatik güncelleme gerçekten iyi bir haber, aynı zamanda dikkatli bakmak için sebep. Otomatik güncelleme yalnızca (a) WP_AUTO_UPDATE_CORE açıkça devre dışı bırakılmamışsa, (b) site kendi çekirdek dosyalarına yazabiliyorsa ve (c) sunucu api.wordpress.org’a ulaşabiliyorsa tetiklenir. Yönetilen barındırma sağlayıcıları dağıtımlarını kendi yollarıyla yamalıyor — WordPress.com, WP Engine, Kinsta, Pressable, Automattic yönetimi, Cloudways cumartesi sabahına kadar bitirmişti. Ucuz paylaşımlı barındırmadaki kendi yönettiği siteler uzun kuyruk. Politika gereği otomatik güncellemeyi kapatan özelleştirilmiş wp-config.php dosyası olan her site sizin sorumluluğunuzdadır.

WooCommerce tarafı aynı hikâye, ama kenarları daha keskin. Yamasız çekirdek üzerindeki bir mağaza yalnızca sızmış bir veritabanı değildir. Saklanan ödeme jetonları, müşteri kişisel verileri, sipariş geçmişi ve sömürünün gerçekleştiği gün ödeme havalelerini yönlendirebilecek kimlik bilgileriyle bir saldırgan demektir. Stripe for WooCommerce, PayPal Payments ve blok Ödeme yığını, hepsi savunmasız toplu istek işleyicisini gönderen aynı REST sunucusunun arkasında oturur. 6.9 veya 7.0 üzerinde yamalı sürümü doğrulanmamış her WooCommerce sitesi, aksi kanıtlanana kadar ele geçirilmiş sayılır. Bu, çerçevenin sakin hâli.

7.1 döngüsünün yeniden düzenlenmesi çoğunlukla sürüm-lider ekipleri ve beta test edenleri ilgilendiriyor. Temmuz geliştirici derlemesi cumadan önce yazıldığından bastığı takvim eski takvim. Bugünün gerçeği şu: Beta 2 17 Temmuz’da yeniden basıldı, fazladan bir beta eklendi ve Beta 1 üzerinde test yapan her eklenti geliştiricisi 29 Temmuz penceresi kapanmadan yeniden basılmış Beta 2’yi çekmeli.

Ne yaparım, ne yapmam

Yönetimimizdeki her WordPress sitesinde bu hafta sonuna kadar dört geçiş, bu sırayla.

1. Sürümü kanıtlayın. Yönetim panelindeki sürüm numarasına güvenmeyin. SSH varsa sunucuda wp core version çalıştırın; yoksa /wp-includes/version.php dosyasına vurun ve $wp_version değerini grep edin. 7.0.2, 6.9.5 veya 6.8.6 altındaki her şey yamalı değil. WordPress 7.1 Beta 1 de yamalı değil — yeniden basılmış Beta 2 veya sonrasını çekin.
2. Otomatik güncellemenin gerçekten çalıştığını doğrulayın. wp-content/upgrade/ altında 17 veya 18 Temmuz tarihli WordPress-7.0.2 klasörüne bakın, Araçlar > Site Sağlığı > Bilgi > WordPress bölümündeki güncel sürümü kontrol edin ve site otomatik güncellemeyi kapatan bir politika altındaysa yamayı bir insanın uyguladığını teyit edin. Bu hafta en tehlikeli siteler “otomatik güncelleme açık” diye kimsenin bakmadığı sitelerdir.
3. İki cuma arasında 6.9 veya 7.0 üzerinde olan her siteyi ihlal göstergelerine karşı tarayın. Sunucu günlüklerinde 17 Temmuz 15:00 UTC öncesine ait /wp-json/batch/v1 veya /index.php?rest_route=/batch/v1 uç noktalarına POST isteklerini arayın. Aynı pencerede wp-content/ altında sizin dağıtmadığınız değiştirilmiş PHP dosyalarını dosya sisteminde grep edin. wp_options tablosunda alışılmadık autoload girişleri, wp_users tablosunda yeni yönetici hesapları ve nesne önbelleğinde yerleştirilmiş zamanlanmış işler için bakın.
4. Müşteri iletişim şablonunuzu güncelleyin. Başkası adına WordPress yönetiyorsanız “sitenizin yamalı sürümde olduğunu doğruladık” mesajını çoktan göndermiş olmalıydınız. Göndermediyseniz şimdi gönderin. Kamuya açık bir RCE penceresinde sessizlik, ajansların danışmanlık gelirini kaybetme biçimidir.

İki şeyi yapmam. REST API’yi bir azaltım olarak toptan kapatmam — blok düzenleyici, WooCommerce Store API ve her modern entegrasyon buna bağlı, ayrıca zaten yamalısınız. 6.8.6 geriye taşımasını sonsuza kadar 6.8’de kalmak için yeşil ışık olarak görmem; çekirdek güvenlik ekibi yalnızca güncel ana sürümün aktif desteklendiğini net dile getirdi ve bu döngü o iyi niyetin son parçasını kullandı. Hâlâ eski daldaki her sitede 6.8’den 7.0.x’e geçişi bir sonraki olay öncesinde planlayın, çünkü bir sonraki olay olacak ve geriye taşıma o kadar uzağa gitmeyebilir.

Kötü bir cumanın rahatlatıcı yanı, sürecin işlediğini izlemektir. HackerOne üzerinden eşgüdümlü açıklama, dört dalda aynı gün yama, sürüm kanalı üzerinden zorunlu güncelleme, bozuk bir ana sürüm göndermek yerine yeniden düzenlenmiş bir beta takvimi. WordPress yönetişim katmanı hakkını veriyor. Bizim işimiz son ayağın — müşteri alanı altındaki sitenin — güncellemeyi gerçekten aldığından emin olmak.