WP2Shell (CVE-2026-63030): WordPress Core Pre-Auth RCE Zincirinin Cortex XDR ile Davranışsal Tespiti

WAF signature'ı yayılmadan, yama tüm sunuculara ulaşmadan, endpoint tarafında ne yapabiliriz?

Yönetici Özeti

17 Temmuz 2026 tarihinde WordPress Core'da CVE-2026-63030 koduyla kritik bir pre-authentication uzaktan kod çalıştırma (RCE) zafiyeti açıklandı. Güvenlik topluluğunda "wp2shell" olarak anılan bu açık, WordPress REST API'nin batch endpoint'inde bir route confusion ile SQL injection'ın zincirlenmesinden kaynaklanıyor. Saldırganın hiçbir kimlik bilgisine, hesaba veya kurulu eklentiye ihtiyacı yok, stock bir kurulum bile etkileniyor. Etkilenen sürümler 6.9.0 - 7.0.1 aralığında; yamalı sürümler 6.9.5, 7.0.2 ve 7.1 Beta 2. Rapid7 kamuya açık bir PoC'nin kısa süre içinde yayınlanmasını bekliyor. Forumlarda dolaşan wp2shell-fast adlı otomasyon aracı ile zafiyetin ilk erişim brokerları (IAB) ve ransomware operasyonları için "internet ölçeğinde toplu shell alma" fırsatına dönüşme potansiyeli yüksek. Bu yazıda zafiyetin teknik iç yüzünü, hangi katmanlarda ne yapılması gerektiğini ve Cortex XDR tarafında deploy edilebilecek 5 BIOC + 1 retrospektif hunt sorgusunu ele alıyoruz.

Zafiyet Neye Yol Açıyor?

WordPress REST API'nin /wp-json/batch/v1 endpoint'i, WordPress 6.9 ile olgunlaşmış bir özellik. Amacı, tek bir HTTP isteği içinde birden fazla REST çağrısını sıralı biçimde yürütmek, geliştiriciler için performans kolaylığı. Zafiyet, bu batch işleyicisinin iç yönlendirmesindeki bir route confusion ile alt isteklerin parametre doğrulamasının atlanabilmesinden doğuyor.

Rota karışıklığı sonucu, normalde güvenli sayılan WP_Query parametreleri (kamuya açıklanan detaylarda özellikle author__not_in) beklenmeyen bir bağlamda, yeterli sanitizasyon olmadan sorguya ulaşıyor. Bu, SQL injection zincirinin ilk halkası. Yamada değişen çekirdek dosyalar arasında class-wp-query.php'nin bulunması bu tespiti destekliyor. SQL injection, veritabanı okuma kabiliyetinden başlıyor ve zincirin son halkasında, araştırmacıların savunuculara yama süresi tanımak için bilinçli olarak geciktirdiği kısımda, kod çalıştırmaya ulaşıyor.

Zafiyetin bir tek önkoşulu var: kalıcı bir object cache (Redis/Memcached tabanlı) devrede değilse zafiyetli kod yolu tetiklenebiliyor. Object cache aktif olan kurulumlar geçici bir sertleştirme sağlıyor, ancak yamanın yerine geçmiyor. Sadece bir istismar yolunu daraltıyor.

Saldırının pratik akışı şöyle: FOFA veya Shodan benzeri motorlarla zafiyetli sürüm bandındaki (6.9.x / 7.0.x) siteler toplu tespit ediliyor. Batch endpoint'e tek istekle pre-auth RCE tetikleniyor ve genellikle wp-content/uploads veya tema dizinine bir webshell bırakılıyor. Sonrasında webshell üzerinden sahte mu-plugin, cron job veya wp_options içine gömülü zararlı kod ile persistence sağlanıyor. Aynı sunucudaki wp-config.php'nin içindeki DB kimlik bilgileri, yedekler, iç ağ erişimi haritalanıyor. Müşteri veritabanları exfil için dışa aktarılıyor ve son adımda web kök dizini şifreleniyor. WordPress kurulumları genelde DB + yedek + bazen iç ağ ile aynı makinede olduğundan, tek bir shell noktası çift taraflı şantaj (double extortion) için yeterli oluyor.

Neden WAF ve Yama İlk Öncelik

wp2shell'i durdurmanın en etkin yolu güncel sürüme geçmek. Yönetilen ortamlarda auto-update kanalı zorunlu güncelleme başlatmış olsa da, çoğu kurumsal WordPress kurulumunda otomatik güncelleme kapalıdır, özellikle özelleştirilmiş tema veya eklenti kullanan sitelerde. wp core version ile fiili sürümün doğrulanması kritik.

İkinci katman, WAF veya reverse proxy tarafında sanal yama. Yasal batch API entegrasyonu olmayan siteler için /wp-json/batch/v1 endpoint'inin doğrudan 403 döndürecek şekilde bloklanması yeterli. Bypass için sıkça kullanılan rest_route=/batch/v1 query-string varyantı ve encoded karşılığı rest_route=%2Fbatch%2Fv1 da unutulmamalı. ModSecurity, Cloudflare veya bulut WAF üzerinde tek kural ile üç varyant da kapatılabilir.

Üçüncü katman, sertleştirme. wp-content/uploads/ altında PHP yürütmesinin Nginx/Apache seviyesinde kapatılması, webshell drop edilse bile execute edilmesini engelliyor. Kalıcı object cache aktifleştirmek zafiyetli kod yolunu daraltıyor. REST API'ye anonim erişimi kısıtlayan bir mu-plugin ile batch route'una kimlik doğrulama zorunlu kılınabilir.

Peki bu üç katman kurulmadan önce, ya da hiç kurulamadıysa, EDR/XDR tarafında ne yapılabilir? Yazının geri kalanı bu soruya odaklanıyor.

Etkilenen ve Yamalı Sürümler

Ön koşul: Kalıcı bir object cache (Redis/Memcached) devrede değilse zafiyetli kod yolu tetiklenir. Object cache aktif kurulumlar geçici bir sertleştirme sağlar; yamanın yerine geçmez.

Cortex XDR Tarafında Ne Görülüyor, Ne Görülmüyor?

php-fpm ve nginx, WordPress ekosistemindeki en meşru servislerden. İmzalı, standart, neredeyse hiç sorgulanmadan çalışmasına izin verilen bileşenler. Görevleri, web sunucusunun devrettiği PHP kodunu işletmek.

Ama saldırgan batch endpoint'inden içeri girdiği anda bu servisler saldırganın süreç ağacının en tepesine yerleşiyor. Ağa çıkmıyor, oturum açmıyor; komut zaten www-data olarak koşuyor. XDR'ın gördüğü tablo, sıradan web sunucusu aktivitesinden farksız görünüyor. Üç yapısal sebep aynı anda devrede:

Birincisi, php-fpm ve nginx'in publisher güven seviyesi yüksek. Cortex XDR'ın Behavioral Threat Protection davranışsal puanlaması bu servislerin ürettiği alt süreçler için eşiğin altında kalıyor.

İkincisi, istismar HTTP kanalıyla geliyor. Cortex Linux agent'ı network katmanında IPS gibi imza taraması yapmıyor. WAF veya reverse proxy tarafında ayrı bir signature yoksa Initial Access aşaması agent tarafında hiç görünmüyor.

Üçüncüsü, etkileşimli oturum açılmamış. www-data bir kullanıcı değil, servis hesabı; SSH veya logon korelasyon kanalı da yok.

Kısacası nginx → php-fpm → sh zinciri, tek başına Cortex'in default iz sürme listesinde yer almıyor. Kaydediliyor, sınıflandırılıyor, ama bir uyarıya dönüştürülmüyor. Bu boşluğun kapatılabilmesi için Cortex XDR Console → Detection Rules → BIOCs altına aşağıdaki beş davranışsal kuralın eklenmesi önerilir.

Canlı Test, Saldırı Başlamadan Engellendi

Kural önerilerine geçmeden önce, davranışsal tespit yaklaşımının pratikte ne kadar erken müdahale edebildiğini kontrollü bir laboratuvar üzerinde gözlemledik. Cortex XDR, saldırının defense evasion fazını (T1036.004 Masquerading) süreç doğmadan, kernel seviyesinde inline durdurdu.

Fake kernel thread'i başlatmaya çalışan exec -a komutu, hedef süreç (Target Process) doğmadan blok edildi; bu nedenle "Target Process" alanı boş kaldı, ki bu gecikmiş değil, önlenmiş bir tespit göstergesidir.

Bu tespit, aşağıda paylaşılan custom BIOC kurallarımızdan bağımsız olarak Cortex XDR'ın Behavioral Threat Protection modülü tarafından üretildi.

Cortex XDR Kural Önerileri

BIOC 1, Web Sunucusu Kullanıcısından Shell Doğması

MITRE: T1059.004Aşama: Post-ExploitationSeverity: CriticalAction: Prevent

RCE'nin en direkt kanıtı. php-fpm veya nginx normalde bash, curl veya python çağırmaz. Bu davranış exploit'in son halkasını (kod çalıştırma) direkt gösterir.

BIOC 2, wp-content/uploads Altına PHP Dosyası Yazımı

MITRE: T1505.003Aşama: PersistenceSeverity: CriticalAction: Prevent

WordPress'in uploads/ dizini sadece görsel/PDF gibi statik dosyalar içindir. Buraya yazılan herhangi bir .php dosyası, isim ne olursa olsun webshell drop'udur. Dosya adı bazlı IOC yaklaşımından bağımsız, attacker rename etse bile yakalanır.

BIOC 3, Kernel Thread Kılığına Girmiş Sahte Süreç

MITRE: T1036.005Aşama: Defense EvasionSeverity: CriticalAction: Prevent

Gerçek [kworker/x:y] kernel thread'lerinin command line'ı yoktur, sadece isim vardır. Command line varsa süreç kesin malicious. WP-Shellstorm ve benzeri WordPress compromise kampanyalarının klasik gizleme tekniği; false positive oranı sıfıra yakındır.

BIOC 4, Bilinen Webshell İsim İmzaları

MITRE: T1505.003Aşama: PersistenceSeverity: HighAction: Prevent

Sektörde raporlanan wp2shell ve WP-Shellstorm kampanya IOC'leri. BIOC 2'nin (path-based) hızlı tamamlayıcısı, bilinen imzaları anında yakalar, path filtresi olmadan da tetiklenir.

BIOC 5, Web Sürecinden Dış Ağa C2 Bağlantısı

MITRE: T1071.001Aşama: Command & ControlSeverity: HighAction: Detect (baseline sonrası Prevent)

Compromise sonrası webshell sıklıkla ek payload çeker veya C2 beacon açar. Private IP aralıkları hariç tutuluyor; kalan outbound bağlantılar dış ağa gidiyor demektir. WordPress otomatik güncelleme veya wp-cli gibi araçlar için istisna gerekebilir, bu yüzden önce Detect modunda başlatılmalı.

Retrospektif Hunt, "Biri Çoktan Girdi Mi?" Sorusu

BIOC'lar bugünden sonrası için savunma katmanı sağlar. Zafiyet 17 Temmuz'da açıklandı - ya o tarihten önceki günlerde ortamdaki hangi endpoint'lerde bu URL izi kaldı? Cortex XDR Linux agent'ı endpoint tarafında HTTP URL'lerini doğrudan göremediği için retrospektif hunt DNS sorguları üzerinden yürütülür. Aşağıdaki sorgu, web sunucusu process'lerinin dış ağa yaptığı DNS sorgularını listeler, XQL Search'te Last 30 days aralığında çalıştırıldığında geriye dönük tarama yapar. Bilinen C2 domain listesi varsa dns_query_name in (...) ile filtrelenebilir.

Kural Özet Tablosu

BIOC 1, 3 ve 4'ün doğrudan Prevent ile başlatılması değerlendirilebilir; FP profili düşük, high-confidence malicious davranışları kapsar. BIOC 2 ve 5 için önce Detect modu önerilir; WordPress otomatik güncelleme, paylaşımlı hosting deploy'ları veya wp-cli cron çalışmaları için istisna tanımlanması faydalı olacaktır. 7 gün baseline gözlemi sonrası Prevent'e geçirilmesi düşünülebilir.

Öneri Adımları

Yüksek Öncelik

Tüm WordPress varlık envanterinin çıkarılması ve sürümlerin WPScan, wp core version veya HTTP başlıkları / readme.html üzerinden tespit edilmesi önerilir. 6.9.x ve 7.0.x bandındaki varlıkların "yamaya kadar şüpheli" olarak değerlendirilmesi uygun olacaktır.

WAF veya Nginx tarafında /wp-json/batch/v1, rest_route=/batch/v1 ve encoded varyant rest_route=%2Fbatch%2Fv1 için engelleme kuralı eklenmesi önerilir. Yasal batch API entegrasyonu bulunmayan ortamlarda doğrudan return 403 yaklaşımı düşünülebilir.

Cortex XDR üzerinde Prevent ve Detect modunda BIOC kurallarının yazılması önerilmektedir. Yüksek confidence taşıyan kurallar doğrudan Prevent, false positive potansiyeli bulunan kurallar ise baseline gözlemi tamamlanana kadar Detect modunda çalıştırılabilir.

Retrospektif hunt sorgusunun son 30 gün üzerinde XQL Search'te çalıştırılması faydalı olacaktır. Eşleşme bulunması durumunda IR playbook'a geçilmesi önerilir.

Orta Öncelik

WordPress varlıklarının 6.9.5 / 7.0.2 / 7.1 Beta 2 sürümüne yükseltilmesi ve auto-update kanalının fiilen uygulandığının doğrulanması önerilir.

wp-content/uploads/ altında PHP yürütmesinin Nginx/Apache seviyesinde kapatılması, webshell drop olsa bile execution'ı engelleyen ikinci bir savunma katmanı sağlayabilir.

Kalıcı object cache (Redis veya Memcached) devreye alınması, zafiyetli kod yolunu daraltan ek bir katman olarak değerlendirilebilir.

FIM (dosya bütünlüğü izleme) ile web kök dizininin izlemeye alınması faydalı olabilir. Özellikle wp-config.php, .htaccess ve wp-content/mu-plugins/ dizinleri kritik önem taşımaktadır.

Bulgu Halinde, IR Playbook

Hunt sorgusu veya BIOC bir eşleşme ürettiğinde standart IR akışı:

1. İzole et: Etkilenen host'u Cortex XDR üzerinden ağa kapat; Apache/Nginx servisini durdur.
2. Artifact topla: wp-content/uploads, wp-content/plugins, wp-content/mu-plugins, .htaccess, wp-config.php ve son 30 günlük Apache access logları alınmalı.
3. Kimlik rotasyonu: DB kredensiyeli, WordPress SECURE_AUTH_KEY / NONCE_KEY tuzları, admin şifreleri ve API token'ları rotate edilmeli; yeni oluşturulmuş suspicious admin hesapları silinmeli.
4. Persistence temizliği: Sahte mu-plugin, cron job (wp_options içindeki cron serialize alanı), _transient_* anahtarları ve son 30 günde değişmiş core dosyaları denetlenmeli.
5. Retrospektif genişletme: Aynı web sunucusu process ağacında C2 domain'lerine yapılan DNS sorguları ve lateral movement izleri (SSH, DB bağlantıları) taranmalı.
6. Yeniden inşa: Sunucu bütünlüğü güvenilir doğrulanamıyorsa temiz image üzerinden yeniden kurulmalı; yedeklerden geri dönüş öncesi backup'ın zafiyet penceresi öncesine ait olduğu doğrulanmalı.

Sonuç

CVE-2026-63030 "wp2shell", WordPress ekosisteminin son yıllarda karşılaştığı en kritik zafiyetlerden biri. Pre-auth + core + RCE üçlüsü, saldırganlara internet ölçeğinde otomasyon fırsatı sunuyor. Yamanın uygulanması ilk ve en önemli katman olarak öne çıkıyor; ancak yama içeri girmiş olanı çıkarmaz, bu nedenle retrospektif hunt ve davranışsal EDR/XDR kurallarının eş zamanlı olarak devreye alınması önerilir.

Yukarıdaki beş BIOC + bir hunt sorgusu Cortex XDR ortamında deploy edildiğinde wp2shell'in kill-chain'inin her aşamasını yakalayabilecek kapsayıcı bir savunma katmanı oluşturuyor. Web sunucusu kullanıcısından şüpheli süreç doğması ve web dizinine PHP yazılması gibi davranışlar exploit'in iç detayından bağımsız olduğu için, aynı kurallar wp2shell dışındaki gelecek WordPress RCE'lerine karşı da koruma sağlayacak.

Ömer Kaan Kurt - L1 MDR Analyst
InfinitumIT MDR - Detection Engineering & Threat Hunting

Bu yazı, gerçek EDR/XDR ortamlarında uygulanan davranışsal tespit prensipleri temel alınarak hazırlanmıştır. Kurallar production kullanımına almadan önce ortamınıza özel istisna baseline'ları oluşturulmalıdır.