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

🇬🇧 English: Read this in English →

WordPress’i yirmi yıldır üretim ortamında koşturmak sana güvenlik sürümleri hakkında iki şey öğretir. Sıkıcı olanları çarşamba günü uygularsın. İlginç olanları ise düştüğü anda uygularsın, 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. Açık konuşayım: 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. Gece boyunca otomatik güncelleme aldığından emin olduğun 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ğin 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 senin sorumluluğunda.

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ıtla. Yönetim panelindeki sürüm numarasına güvenme. SSH varsa sunucuda wp core version çalıştır; yoksa /wp-includes/version.php dosyasına vur ve $wp_version değerini grep et. 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ı çek.
2. Otomatik güncellemenin gerçekten çalıştığını doğrula. wp-content/upgrade/ altında 17 veya 18 Temmuz tarihli WordPress-7.0.2 klasörüne bak, Araçlar > Site Sağlığı > Bilgi > WordPress bölümündeki güncel sürümü kontrol et ve site otomatik güncellemeyi kapatan bir politika altındaysa yamayı bir insanın uyguladığını teyit et. 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şı tara. 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 ara. Aynı pencerede wp-content/ altında senin dağıtmadığın değiştirilmiş PHP dosyalarını dosya sisteminde grep et. 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.
4. Müşteri iletişim şablonunu güncelle. Başkası adına WordPress yönetiyorsan “sitenin yamalı sürümde olduğunu doğruladık” mesajını çoktan göndermiş olmalıydın. Göndermediysen şimdi gönder. 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. 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 planla, çünkü bir sonraki olay olacak ve geriye taşıma o kadar uzağa gitmeyebilir.

Ya bir ihlal göstergesi bulursan: ilk saat

Yukarıdaki taramada temiz çıkarsan ne mutlu. Ama açık konuşayım: kamuya açık bir RCE penceresinde 6.9 veya 7.0 üzerinde yamasız kalmış bir siteyi denetlerken, bulmayı umduğun değil, bulman gereken şeyi ararsın. Şüpheli bir dosya, yeni bir yönetici hesabı ya da tanımadığın bir zamanlanmış iş çıkarsa, sadece yamayı geçmek yetmez — yama açığı kapatır, ama zaten içeri girmiş birini dışarı atmaz. Sıra şu:

1. İzole et, silme. Siteyi bakım moduna al ya da barındırma seviyesinde geçici olarak kapat. Kanıtı yok etme; adli iz sonra lazım olacak.
2. Yamadan önceki bir yedeği kenara al. Ele geçirilmiş hâli bile olsa, saldırganın neyi değiştirdiğini karşılaştırabileceğin tek referans o.
3. Bütün sırları döndür. wp-config.php içindeki tuz anahtarları, veritabanı parolası, tüm yönetici parolaları, ödeme ağ geçidi API anahtarları ve SMTP kimlik bilgileri. RCE penceresinde bunların hepsi sızmış varsayılır.
4. Çekirdeği ve eklentileri temiz kopyadan yeniden kur. wp core download --force ve eklentileri depolarından yeniden yükle; enjekte edilmiş dosyaları elle temizlemeye çalışma, bir tanesini kaçırırsın.
5. WooCommerce ise, olayı ödeme sağlayıcına ve gerekiyorsa KVKK/GDPR açısından bildir. Sipariş ve müşteri verisi söz konusuysa bu artık bir teknik mesele değil, bir uyum meselesi.

Bunu buraya yazmamın sebebi karamsarlık değil. Çoğu site otomatik güncellemeyle temiz çıkacak. Ama bir müdahale planını olay anında yazmaya kalkarsan geç kalırsın; şimdi, sakinken bir kez okumak bütün farkı yaratır.

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.