WordPress panelinde bütün eklentilerin güncel görünmesi bu kontrolün yerini tutmaz. Sorun uygulamanın altındaki PHP katmanındadır. 23 Ekim 2026 itibarıyla yamalar yayımlanmış durumda; aşağıdaki sürüm tablosu ve kontrol sırası, hosting desteğine ne soracağınızı da netleştiriyor.
PHP2Shell Nedir, 9,2 Puan Ne Anlama Geliyor?
PHP2Shell bir eklentinin veya virüsün adı değil. İki açığı birlikte anlatmak için kullanılan isim. İlk PHP güvenlik kaydı bellek tükenmesi sırasında oluşan bozulmayı, ikincisi önceki istekten kalan geçersiz bellek başvurularını ele alıyor. RCE, saldırganın uzaktaki sistemde kod çalıştırabilmesi demek; burada erişimin sınırını PHP işleminin yetkileri de belirliyor. Bu, her durumda sunucunun en yetkili hesabının ele geçirilmesi anlamına gelmez.
9,2 “kritik” sınıfındadır; sitenizin yüzde 92 olasılıkla ele geçirileceğini göstermez. Kullandığınız sürüm, çalışma biçimi ve uygulamanın izlediği yollar gerçek riski etkiler. PHP’nin web isteğini nasıl işlediğine yabancıysanız PHP’nin sunucu tarafında nasıl çalıştığına kısa bir göz atabilirsiniz.
Kimler Etkileniyor, Hangi PHP Sürümüne Geçilmeli?
WordPress, Drupal, Joomla veya özel bir PHP uygulaması kullanmanız tek başına fark yaratmaz: alttaki PHP’nin yama durumuna bakılır. Google Cloud’un duyurusu da bulut hizmetinin kendi durumu ile müşterinin çalıştırdığı PHP uygulamasını ayrı değerlendiriyor. “Buluttayız, sağlayıcı halletmiştir” varsayımı yeterli değil.
Tüm sütunlar için tabloyu yana kaydırın. Klavyeyle tabloya odaklanıp ok tuşlarını kullanabilirsiniz.
| PHP Dalı | Düzeltmeyi İçeren Sürüm | Kontrol |
|---|---|---|
| 8.5 | 8.5.12 | Aynı daldaki bu sürüm veya daha yeni güvenlik güncellemesi |
| 8.4 | 8.4.27 | Yalnız “8.4 kullanıyoruz” bilgisi yetmez |
| 8.3 | 8.3.36 | Son noktadan sonraki sürüm de kontrol edilir |
| 8.2 | 8.2.35 | Bu yama, dalın destek ömrünü uzatmaz |
| 8.1 ve Daha Eski | Sağlayıcıya ve Pakete Bağlı | Geri taşınmış yama kanıtı veya desteklenen sürüme geçiş gerekir |
Tablonun dayanağı PHP’nin resmî güvenlik duyurusu. Eski sürümler için bazı dağıtıcılar düzeltmeyi mevcut pakete geri taşıyor. Örneğin Plesk’in Linux paketlerinde 7.4, 8.0 ve 8.1 için sürüm numarası aynı kalıp derleme tarihi değişebiliyor. Bu nedenle yalnız numaraya bakarak “kesin yamalı” veya “kesin yamasız” demeyin; paket duyurusunu da isteyin.

Apache’nin mod_php modülü öne çıkan saldırı yollarından biri; Nginx/PHP-FPM kullanmak ise otomatik muafiyet sağlamıyor. FPM dâhil farklı çalışma yolları güvenlik kayıtlarında ayrıca ele alınıyor. Sunucu yazılımının adına göre güncellemeyi atlamayın.
Sitenizin PHP Sürümünü Nereden Görebilirsiniz?
WordPress: Araçlar → Site Sağlığı → Bilgi → Sunucu yolunu izleyin ve PHP sürümünü okuyun. Site Sağlığı’nın Bilgi sekmesi bilgi gösterir; PHP paketini buradan güncellemezsiniz. “WordPress sürümü” satırıyla karıştırmayın.
cPanel: Yazılım bölümündeki MultiPHP Manager’da ilgili alan adını bulun. cPanel belgesine göre farklı alan adları farklı PHP sürümleri kullanabilir. Menü görünmüyorsa sağlayıcınızdan alan adınıza atanmış sürümü ve paket düzeltmesini teyit etmesini isteyin.

Terminalde php -v çalıştırmak yardımcı olur, ancak komut satırındaki PHP sitenin kullandığı işlemle aynı olmayabilir. Tam sürümü, alan adını ve kullanılan PHP çalışma biçimini birlikte kaydedin. Genel erişime açık bir phpinfo() sayfası bırakmayın; bu çıktı sunucu yolları ve yapılandırma gibi gereğinden fazla bilgi gösterebilir.
Site Sahibi Olarak Şimdi Ne Yapmalısınız?
- Kapsamı belirleyin. Ana siteyle birlikte alt alan adlarını, eski uygulamaları ve internete açık test kurulumlarını listeleyin. Her birinin hangi PHP paketini kullandığını sorun.
- Yedek ve uyumluluğu kontrol edin. Dosya ve veritabanını birlikte koruyun. Özellikle başka bir PHP dalına geçilecekse önemli işlemleri ayrı test ortamında deneyin. WordPress’in PHP güncelleme belgesi de tema ve eklenti uyumluluğunun ayrıca değerlendirilmesini öneriyor.
- Doğru paketi güncelleyin. Paylaşımlı hostingde bunu sağlayıcı yapabilir. Kendi sunucunuzu yönetiyorsanız dağıtıcınızın güvenlik paketini uygulayın; PHP işlemlerinin yeni paketle çalışmaya başladığını doğrulayın.
- Sonucu yeniden okuyun. Güncelleme öncesi ve sonrası paket bilgisini karşılaştırın. Giriş, form, dosya yükleme ve varsa alışveriş akışını test ortamında kontrol edin; yalnız ana sayfanın açılması bütün işlemleri doğrulamaz.
Hosting desteğine şu soruyu gönderebilirsiniz: “Alan adımın web isteklerini işleyen PHP paketi, CVE-2026-109618 ve CVE-2026-109619 için yamalı mı? Paket sürümü/derleme bilgisi, uygulama zamanı ve PHP işlemlerinin yenilendiğine ilişkin teyidi paylaşabilir misiniz?”
“Güvenlik sistemimiz var” cevabı bu soruları yanıtlamaz. Bakım sorumluluğunun pakete dâhil olup olmadığını anlamak için WordPress hosting seçimindeki teknik kontroller de yardımcı olur.
Açık Neden Oluştu?
PHP, bir isteği işlerken bellekte geçici veriler tutar. İş beklenmedik bir anda durduğunda bu verilerin güvenli biçimde temizlenmesi gerekir. PHP2Shell’de sorun, hata sonrası temizlik ve sonraki isteğe geçiş sırasında ortaya çıkıyor.
CVE-2026-109618’de yarım hazırlanmış veri daha sonra geçerliymiş gibi kullanılabiliyor. CVE-2026-109619’da ise artık serbest bırakılmış belleğe işaret eden eski durum sonraki isteğe taşınabiliyor. Wiz’in araştırması bu davranışların uygulama katmanından daha aşağıda olduğunu açıklıyor. Bir formdaki hatayı düzeltmek, PHP çalışma ortamındaki bütün yolları kapatmış olmaz.

Yapay Zekâ Nasıl Buldu, Neden Daha Önce Çözülmedi?
“Yapay zekâ açığı buldu” cümlesinin arkasında insan araştırmacılar, araçlar ve doğrulama çalışmaları var. Calif’in araştırma anlatımı, geçmiş bulgulardan hareket eden araştırmacıların AI desteğiyle olası yolları incelediğini gösteriyor. Açığın keşfiyle çalışan bir saldırı olasılığının kanıtlanması aynı aşama değil.
PHP Foundation’ın açıklamasına göre bellek tükenmesi sorununun belirtileri 2024’te görülmüştü. Uyumluluk, performans ve geliştirici kaynağı sorunları çözümü geciktirdi; 2026’daki araştırmalar etkinin ciddiyetini netleştirdi. Kurum karar sürecindeki aksaklığı da kabul ediyor. Dolayısıyla “dün ortaya çıktı” demek kadar, bütün ayrıntıları aynı kalmış tek bir açığın onlarca yıldır bilindiğini söylemek de eksik olur.
Cloudflare, Güçlü Parola veya Bir Ayar Yeterli mi?
WAF, web isteklerini süzen güvenlik katmanıdır. Cloudflare PHP2Shell için kurallar yayımladı; şirket aynı duyuruda PHP yamasının yine uygulanmasını istiyor. Bir güvenlik ürününün açık olması, bütün saldırı yollarının kapandığı anlamına gelmez.
Güçlü parola ve iki aşamalı doğrulama hesaplar için değerlidir; giriş gerektirmeyen bir PHP açığını onarmaz. Bellek veya yükleme ayarlarını gelişigüzel değiştirmek de kalıcı çözüm sayılmaz. Hemen güncellenemeyen sistemde geçici önlemleri sunucu sorumlusu belirlemeli; PHP’nin duyurusu bunların yalnız belirli yolları azalttığını açıkça belirtiyor.
Güncelledikten Sonra İş Bitiyor mu?
Yamayı uygulamakla daha önce bir saldırı yaşanıp yaşanmadığını araştırmak ayrı işler. Beklenmeyen dosya değişikliği, bilinmeyen yönetici hesabı veya olağandışı işlem varsa kayıtları koruyup sağlayıcınızla inceleyin. Belirti görmemek de tek başına temiz olduğunuzun kanıtı değildir. Bu yazı belirli bir sitenin saldırıya uğradığını veya güvenli olduğunu doğrulamaz.
Benzer Bir Açık Tekrar Bulunabilir mi?
Benzer açıklara tekrar rastlanabilir; bunun tarihini veya şiddetini önceden söyleyemeyiz. Kalıcı alışkanlık, kullanılan yazılımların ve sorumlularının listesini tutmak, güvenlik duyurularını takip etmek ve güncellemenin gerçekten uygulandığını kontrol etmektir. Hesap ve cihaz tarafındaki günlük güvenlik önlemleri de bu bakımın diğer parçasıdır.
PHP güncellemesi sonrasında sitenizin form, üyelik veya mağaza akışını kimin kontrol edeceği belirsizse, web sitesi bakım ve geliştirme kapsamını birlikte netleştirebiliriz. Kullandığınız altyapıyı ve sağlayıcınızın yama teyidini paylaşmanız, ihtiyaç duyulan işi belirlemek için yeterli bir başlangıçtır.





