22 Eylül 2026'da, Ulusal Gün tatilinin arifesinde, WordPress CVE-2026-87902'yi kapatmak için 7.1.2 güvenlik güncellemesini yayımladı. Açık bir eklentide ya da temada değil. WordPress çekirdeğinde ve 4.7.0'dan 7.1.1'e kadar her sürümü etkiliyor. Aynı gün saat 11:49 UTC'de (Riyad saatiyle öğleden sonra 2:49), güvenlik şirketi Patchstack açığı istismar etmeye yönelik ilk girişimi gördü ve dört saatten kısa bir süre sonra da bir sitenin sunucusuna dosya yazmaya yönelik ilk girişimi.

Saldırı beş günde nasıl yayıldı

Sonra yayıldı. CrowdSec'in bugün, 28 Eylül'de yayımladığı rapora göre ağı, 23 ve 27 Eylül arasında 30.813 farklı IP adresinden açığa uyan 322.680 saldırı sinyali kaydetti; zirve 27 Eylül'de 124.154 sinyalle görüldü. Suudi Arabistan Ulusal Siber Güvenlik Otoritesi (NCA) 23 Eylül'de 2026-7873 numaralı Kritik bir uyarı yayımladı, ABD kurumu CISA da 25 Eylül'de açığı bilinen istismar edilmiş güvenlik açıkları kataloğuna ekledi.

Açık ne yapıyor, basitçe

Bir ziyaretçi bir sayfa istediğinde WordPress, sayfayı göstermek için temanın hangi şablon dosyasını kullanacağına karar verir. Hata bu adımdadır: oturum açmamış bir saldırgan bu adımı sunucuda tema klasörünün dışında duran bir PHP dosyasına yönlendirebilir ve WordPress o dosyayı çalıştırır. WordPress açığı 10 üzerinden 9.2 olarak, CISA ise 8.1 olarak derecelendiriyor.

WordPress güvenlik bildiriminde ve araştırmacıların raporlarında belirtilen koşullar bir araya geldiğinde, açık sitenin ele geçirilmesine dönüşür:

  • Tema: etkin tema, adı page- ile başlayan bir klasör içerir. Bildirim, bu klasöre sahip temalar arasında Twenty Twelve, Twenty Fourteen, Neve, Hestia ve Sydney'i sayıyor.
  • Bir PHP ayarı: register_argc_argv açıktır; CrowdSec'e göre bu, resmi PHP Docker imajlarında ve 8.5'ten eski PHP çalıştıran cPanel sunucularında varsayılan ayardır.
  • Yardımcı bir dosya: PEAR'ın pearcmd.php dosyası sunucuda bulunur. Saldırganlar onu yeni PHP dosyaları, yani güncellemeden sonra da ayakta kalan bir arka kapı yazmak için kullanır.

Yani açık her siteyi aynı ölçüde etkilemiyor, ancak Security Affairs durumu şöyle özetliyor: kod çalıştırma, sunucu yapılandırmasının uymasını gerektirir ve pek çok sunucuda uyar. Bir işletme sahibi genellikle hangi temanın etkin olduğunu ya da sunucunun nasıl yapılandırıldığını bilmez; bu yüzden güvenli varsayım, aksi kanıtlanana kadar sitenin risk altında olduğudur.

Saldırı neden haftalar değil saatler içinde geldi

Bir güvenlik güncellemesi, doğası gereği hatanın nerede olduğunu ortaya koyar, çünkü koddaki değişiklik herkese açıktır. Patchstack, ilk yüklerin düzeltmenin kapattığı kalıpla birebir eşleştiğini söylüyor; yani onları yazan kişi bağımsız bir keşiften değil, doğrudan düzeltmenin kendisinden yola çıktı. İlk girişimler, sitelerin nasıl yanıt verdiğini görmek için wp-login.php ve wp-cron.php gibi sıradan WordPress çekirdek dosyalarını istedi, ardından dosya yazmaya geçti.

Trafik ayrıca otomatik tarayıcıların ve yayımlanmış kavram kanıtı (proof-of-concept) kodlarının izlerini taşıyor. Bir işletme sahibi için bu, kimsenin özellikle sizin sitenizi seçmediği anlamına geliyor. Araçlar ulaşabildikleri her WordPress sitesini tarıyor ve ele geçirilmiş bir siteyle temiz bir site arasındaki fark, güncellemenin onlardan önce gelip gelmediğidir.

Siteniz kendi kendine güncelleniyor mu?

Muhtemelen, ama bunu varsaymayın. WordPress'te 3.7 sürümünden beri otomatik arka plan güncellemeleri var ve 5.6'dan beri yeni kurulumlar hem küçük hem de büyük sürümleri otomatik olarak güncelliyor. 7.1.2 duyurusu, otomatik arka plan güncellemelerini destekleyen sitelerin otomatik olarak güncellenmeye başlayacağını söylüyor.

Ancak otomatik güncellemeler wp-config.php dosyasındaki tek bir satırla kapatılabilir. Bazı geliştiriciler bir güncellemenin özelleştirilmiş temayı bozmaması için bunları bilerek kapatır, bazı barındırma firmaları da güncellemeleri kendi tarafında yönetir. Yıllar önce bir serbest çalışanın yaptığı ve sözleşmesi çoktan sona ermiş bir site, kimse fark etmeden eski bir sürümde kalabilir. Kontrol etmek için:

  • Sitenin yönetim paneline giriş yapın, Başlangıç menüsü altındaki Güncellemeler sayfasını açın; mevcut sürümü orada göreceksiniz.
  • Güvenli sürüm 7.1.2 veya sonrasıdır. Siteniz daha eski bir daldaysa düzeltme 4.7'ye kadar her dala ulaştı; bunlar arasında 7.0.6, 6.9.9, 6.8.10 ve 4.7.37 de var; tam liste, kaynaklarda bağlantısı verilen WordPress güvenlik bildiriminde yer alıyor.
  • WordPress'in yalnızca en son sürümün aktif olarak desteklendiğini söylediğini unutmayın. Eski bir dalda bırakılmış bir site bu düzeltmeyi aldı, ama ödünç zamanda yaşıyor. Yeni sürümün bir şirket sitesine neler kattığını WordPress 7.1: öne çıkan yenilikler yazımızda ele aldık.

Elementor da: tek bir bağlantı yeterli

Aynı hafta, popüler WordPress sayfa oluşturucusu Elementor, yalnızca 4.3.0 ve 4.3.1 sürümlerinde bulunan bir açığı düzeltti. Bir site yöneticisi oturumu açıkken özel hazırlanmış bir bağlantıyı açarsa, saldırgan kendi kontrolünde bir yönetici hesabı oluşturabilir; bağlantı e-posta, sohbet ya da yorum yoluyla gelebilir. BleepingComputer'a göre bu sürümler 2 milyona kadar sitede çalışıyor. Düzeltme 24 Eylül'de 4.3.2 ile yayımlandı ve site, yayın sırasında aktif bir istismar bildirmedi.

Elementor'un 4.3.2 veya sonrasında olduğundan emin olun ve bunu bir ekip kuralı haline getirin: sitenin yönetim panelinde oturum açıkken mesajlardaki veya yorumlardaki bağlantıları açmayın.

Siteniz 22 Eylül'den beri güncellenmediyse

  • Hemen güncelleyin: geliştirici güncellemenin bir şeyleri bozacağından endişeleniyorsa, Patchstack yolun pagename parametresindeki dizin geçişi girişimlerini engelleyerek ya da register_argc_argv'yi kapatarak geçici olarak kapatılabileceğini söylüyor. Bu, barındırma firmasının veya geliştiricinin işidir ve güncellemenin yerini tutmaz.
  • Sitenizin yoklandığını varsayın: geliştiriciden veya barındırma firmasından kimsenin eklemediği PHP dosyalarını aramasını isteyin; özellikle /tmp ve /var/tmp içinde, Patchstack burada poc87902.php ve wp-pear-rce-flag.php gibi dosyaları başarılı kod çalıştırmanın işaretleri olarak gösteriyor.
  • Bir şey çıkarsa: bunu bir güncelleme değil, bir olay olarak ele alın. Yönetici hesaplarının, veritabanının ve barındırmanın parolalarını değiştirin, siteyi temiz bir yedekten geri yükleyin, ardından güncelleyin.
  • Site müşteri verisi tutuyorsa: siparişleri, iletişim formlarını veya hesapları saklıyorsa, Suudi Veri ve Yapay Zeka Otoritesi'nin (SDAIA) kişisel veri ihlali olaylarına ilişkin kılavuzu, veri sorumlusunun verilere veya verilerin ait olduğu kişilere zarar verebilecek bir ihlalden haberdar olduktan sonra 72 saat içinde yetkili makamı bilgilendirmesini zorunlu kılıyor.

Origami'nin görüşü

Pek çok şirket sitesi WordPress üzerine kurulur ve sonra basılı bir broşür gibi muamele görür: geliştirici teslim eder, sahibi öder ve kimse onu kimin güncel tutacağını sormaz. Bu açık, bir web sitesinin internete açık bir sunucuda çalışan canlı bir sistem olduğunu ve bir düzeltmenin yayımlanmasıyla bir saldırganın gelmesi arasındaki sürenin artık saatlerle ölçüldüğünü hatırlatıyor. Asıl soru WordPress'in güvenli olup olmadığı değil, çünkü hatayı düzeltti ve düzeltmeyi 4.7'ye kadar her dala gönderdi. Asıl soru, şirketinizde onu yüklemekten kimin sorumlu olduğu.

Bu yüzden bir web sitesi bakım sözleşmesinin kritik güvenlik güncellemelerini yüklemek için azami bir süre belirlemesi, güncellemelerin canlı siteden önce test edildiği bir staging kopyası şart koşması ve sunucunun kendisi dışında saklanan düzenli yedekler tutması gerektiğini düşünüyoruz. Ve tema her güncellemede bozulacak şekilde özelleştirildiği için güncellemeler sürekli erteleniyorsa, bu WordPress'in değil sitenin nasıl kurulduğunun sorunudur ve bir sonraki açıktan önce düzeltilmeyi hak eder.

Sonuç: üç adım

  • Bugün: yönetim panelini açın ve sürümün 7.1.2 ya da dalınızın düzeltilmiş sürümü olduğunu, Elementor'un da 4.3.2 veya sonrasında olduğunu doğrulayın.
  • Bu hafta: geliştiriciden veya barındırma firmasından sunucuyu tanınmayan PHP dosyaları için taramasını ve otomatik güncellemelerin açık olduğunu yazılı olarak teyit etmesini isteyin.
  • Bu ay: bakım sözleşmesine güvenlik güncellemelerini yüklemek için azami bir süre ekleyin ve bundan sorumlu kişiyi belirleyin.

Kaynaklar