PHP2Shell Açığı Nedir? WordPress Siteniz Etkilendi mi?

PHP2Shell, PHP'nin kendisindeki iki kritik güvenlik açığına verilen ad. Açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarını taşıyor, ikisi de 10 üzerinden 9,2 puanla "kritik" sınıfında ve koşullar uygun olduğunda kimlik doğrulaması olmadan sunucuda uzaktan kod çalıştırmaya yol açabiliyor. WordPress sitenizi, temanızı ve eklentilerinizi güncel tutmanız bu açığı kapatmıyor, çünkü sorun WordPress'te değil, WordPress'in üzerinde çalıştığı PHP çalışma ortamında. Çözüm PHP sürümünü düzeltilmiş sürüme çıkarmak: PHP 8.2.35, 8.3.36, 8.4.27 ya da 8.5.12 ve üzeri.

Bu rehberde açığın ne olduğunu, nasıl ortaya çıktığını, sitenizin etkilenip etkilenmediğini nasıl kontrol edeceğinizi, hosting panelinden nasıl güncelleyeceğinizi ve güncelleme gecikirse hangi geçici önlemlerin işe yaradığını anlatıyoruz. Bilgiler 23 Ekim 2026 itibarıyla, aşağıdaki kaynaklardaki açıklamalara dayanıyor. Konu hızlı değiştiği için tarih ve durum bilgilerini kaynaklardan da kontrol edin.

Kısaca: ne yapmalısınız?

1. PHP sürümünüzü öğrenin. WordPress yönetim panelinde Araçlar > Site Sağlığı > Bilgi > Sunucu bölümünde "PHP sürümü" satırına bakın.
2. Düzeltilmiş sürümle karşılaştırın. 8.3 kullanıyorsanız 8.3.36'dan eski bir sürüm risklidir. Hosting sağlayıcınız yamayı sürüm numarasını değiştirmeden uygulamış olabilir, bu yüzden sağlayıcıdan yazılı teyit isteyin.
3. PHP'yi hosting panelinden ya da sağlayıcınızla birlikte güncelleyin. Önce yedek alın, sonra siteyi test edin.
4. Güncelleme hemen yapılamıyorsa aşağıdaki geçici önlemleri sunucu seviyesinde uygulatın. Bunlar tam çözüm değildir.

PHP2Shell nedir?

İki ayrı açıktan oluşuyor ve ikisi de PHP çalışma zamanının (runtime) bellek yönetimiyle ilgili:

Basit bir benzetmeyle: PHP her ziyaretçi isteği için geçici bir çalışma alanı açar, iş bitince alanı temizler. Bu açıklarda temizlik düzgün yapılmıyor ve bir sonraki istek, öncekinin bıraktığı kalıntıya dokunuyor. Saldırgan bu kalıntıyı kontrol edebilirse, sunucuda kendi komutlarını çalıştırabilir.

Araştırmacılar ayrıca, kod çalıştırmadan da PHP işçi süreçlerinin belleğinin dışarıdan okunabildiğini gösterdi. Bu bellekte parola, oturum belirteci ya da API anahtarı gibi hassas bilgiler bulunabilir. Bu yüzden risk yalnızca "site ele geçirilir" ile sınırlı değil.

Neden bu kadar ciddi?

• Sorun uygulamada değil, PHP'nin içinde. Kodunuzu ya da eklentilerinizi mükemmel yazsanız da bu açık sizi korumaz.
• Kimlik doğrulama gerekmiyor. Saldırganın sitede hesabı olması gerekmiyor, internetten ulaşabilmesi yeterli.
• Çok geniş bir sürüm aralığı. Haberlerde sorunun PHP 5.4'e kadar uzanan sürümleri etkilediği belirtiliyor. İngiltere Ulusal Siber Güvenlik Merkezi (NCSC) de yalnızca eski sürümlerle sınırlı kalmamak gerektiğini, tüm PHP sürümlerinin etkilenmiş olabileceğini söylüyor.
• PHP'nin kullanım yaygınlığı. WordPress, WooCommerce, Joomla, Drupal, Laravel ve sayısız özel yazılım PHP üzerinde çalışıyor.
• Saldırı denemeleri başladı. Cloudflare yama öncesinde bile erken sömürü denemeleri gördüğünü ve güvenlik duvarı kuralları devreye aldığını, saldırganların yüklerini bu korumayı atlatmak için değiştirdiğini bildirdi. watchTowr da iki açık için aktif sömürü denemeleri raporladı. Rapid7 ise güvenilir ve genel amaçlı bir sömürü kodu yazmadıklarını, kamuya açık kanıt kodlarının (PoC) belirli işletim sistemi, PHP sürümü ve web sunucusu birleşimlerinde çalıştığını belirtiyor.

Açık nasıl ortaya çıktı? Kronoloji

Olay, "sızıntı" olarak anılıyor çünkü teknik ayrıntılar yama yayımlanmadan önce dolaşıma girdi. Basında aktarılan sıra şöyle:

• 20 Ekim: Bir paylaşımda PHP'de iki uzaktan kod çalıştırma açığının 22 Ekim'de açıklanacağı duyuruldu. Aynı gün akşamı PHP bir ön bildirim yayımladı ve sürümü 21 Ekim'e çekti. Sızıntıda geçen "CVSS 10" ifadesi PHP'nin verdiği puan değildi, resmî puan 9,2.
• 20 Ekim akşamı: Açığı bulan ekiplerden Calif, çalışan kanıt kodunun videosunu yanlışlıkla paylaştı.
• 21 Ekim: Chainguard, yamayı içeren imajları yayımladı. PHP düzeltmeleri aynı gün (yaklaşık 14:00 UTC) resmen çıkardı.

Açığı Wiz Research, Calif ve OpenAI'ın Codex Security ekibi buldu ve PHP güvenlik ekibine bildirdi. Düzeltmeye Google'ın Gemini ekibi de yardım etti. Bir ayrıntı daha dikkat çekici: PHP'nin 2024'teki harici denetiminde bir çekirdek geliştirici, bellek yetersizliği açığının belirtilerini fark etmiş, ancak o dönemde kod çalıştırmaya giden çalışan bir yol bulunamamıştı. PHP Vakfı, düzeltmenin sonraki gecikmesini "yapısal bir başarısızlık" olarak niteledi.

Hangi PHP sürümleri düzeltildi?

Hangi kurulumlar risk altında?

Web isteklerini PHP ile sunan hemen her kurulum kapsamda: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Risk dereceleri farklı:

• Apache mod_php en yüksek öncelikli. Temizlik adımı istek başlatma başarısız olsa bile çalıştığı için sömürü, uygulama kodu çalışmadan önce gerçekleşebiliyor. Rapid7, varsayılan girdi ve bellek limitleriyle bile uzaktan kod çalıştırma raporlandığını belirtiyor.
• PHP-FPM bellek yetersizliği yolunu başlangıç davranışıyla engelliyor. Ancak oturum (session) tabanlı yol FPM üzerinde doğrulandı, yani FPM de yamalanmalı.
• Oturum yükleme ilerlemesi (session upload progress) özelliği varsayılan olarak açık ve ikinci açığa giden yol olarak gösteriliyor. Uygulama session_start() çağırmasa bile eski oturum durumuna erişilebiliyor.
• PHP 8.5'te fatal_error_backtraces varsayılan olarak açık ve mod_php'ye karşı doğrulanmış bir yol sunuyor.

Sömürülebilirlik yapılandırmaya ve uygulamanın davranışına göre değişiyor. Bu "sitem LiteSpeed ya da FPM üzerinde, o halde güvendeyim" anlamına gelmez. Tek tam çözüm güncellemedir.

WordPress siteniz etkilendi mi? PHP sürümünü nasıl kontrol edersiniz?

En hızlı yol WordPress'in kendi aracı:

1. WordPress yönetim paneline yönetici olarak girin.
2. Soldaki menüden Araçlar > Site Sağlığı'na gidin.
3. Bilgi sekmesini açın ve Sunucu bölümünü genişletin.
4. PHP sürümü ve PHP SAPI satırlarına bakın. SAPI satırı sunucunuzun PHP'yi nasıl çalıştırdığını gösterir (litespeed, fpm-fcgi, apache2handler gibi).

Hosting panelinizde de (cPanel, Plesk, DirectAdmin) PHP sürümü ayrıca görünür. İki yerdeki sürüm farklıysa, sitenizin gerçekten kullandığı sürüm WordPress'in gösterdiğidir.

Çok önemli bir ayrım: WordPress'i, temayı ve eklentileri güncellemek PHP'yi güncellemez. THN'nin de vurguladığı gibi, WordPress ya da Laravel gibi uygulamaları güncellemek altındaki PHP çalışma zamanını yenilemez. Bu güncelleme sunucu paketi, hosting sağlayıcı ya da konteyner imajı üzerinden yapılır.

PHP'yi nasıl güncellersiniz?

Paylaşımlı hosting ya da cPanel kullanıyorsanız

1. Önce tam yedek alın (dosyalar ve veritabanı).
2. Hosting panelinde genellikle MultiPHP Manager, PHP Seçici ya da PHP Sürümünü Seç gibi bir bölüm bulunur.
3. Alan adınız için mevcut dalın en güncel sürümünü seçin (ör. 8.3 kullanıyorsanız panelde 8.3.36 ve üzeri görünüyorsa onu).
4. Panel yeni sürümü henüz göstermiyorsa sağlayıcı yamayı sunucuya henüz taşımamış olabilir. Destek talebi açıp şunu sorun: "CVE-2026-109618 ve CVE-2026-109619 için PHP yaması sunucumuzda uygulandı mı? Hangi sürümde uygulanacak?"

VPS ya da özel sunucunuz varsa

• İşletim sistemi paketini güncelleyin ve ilgili hizmeti yeniden başlatın. Debian ve Ubuntu için apt, RHEL tabanlı sistemler için dnf paketlerini kontrol edin. Üçüncü taraf depolar (Remi gibi) güncellemeyi daha geç yayımlayabilir.
• Güncellemeden sonra tüm PHP işçi süreçlerinin yeniden başlatıldığından emin olun. Eski süreç belleği tutmaya devam edebilir.
• Docker kullanıyorsanız temel imajı yeniden çekin ve konteyneri yeniden oluşturun.

Güncellemeden sonra kontrol listesi

• Site Sağlığı'nda yeni sürümü doğrulayın.
• Ana sayfa, iç sayfalar, iletişim formu, ödeme ve üyelik gibi kritik akışları deneyin.
• Yönetim panelindeki "PHP sürümü güncel değil" uyarısı varsa kaybolduğunu kontrol edin.
• Düzeltme sert bir bellek sınırı ekliyor: sınıra ulaşan süreç sonlandırılıyor ve kapanış işleyicileri atlanıyor. memory_limit ve post_max_size değerlerinizi güncellemeden sonra gözden geçirin. Çok büyük dosya yükleyen sitelerde bu değerler ayarlanmalı.

Güncelleme hemen yapılamıyorsa: geçici önlemler

PHP Vakfı ve güvenlik kuruluşları şunu açıkça söylüyor: tek tam çözüm güncellemedir. Aşağıdakiler yalnızca riski azaltır ve genellikle sunucu ayarlarına erişimi olan kişi tarafından yapılmalıdır.

Yapmayın: RLIMIT_AS ya da RLIMIT_DATA ile bellek sınırlamayın, bunlar zafiyetli bellek ayırma hatası yolunu tetikleyebilir. Bellek sınırı için cgroup kullanın. error_reporting, display_errors ya da log_errors ayarlarını kısmak da zafiyeti gizlemez, eski duruma erişim yine olur.

Güncelleme de geçici önlem de uygulanamıyorsa, İngiltere NCSC'nin tavsiyesi sistemi tam önlem alınana kadar çevrimdışı bırakmak. Mümkün değilse, sistemde saldırı izi ve arka kapı (backdoor) taraması yapılması öneriliyor.

Saldırıya uğramış olabilir misiniz? Nelere bakmalısınız?

Henüz ayrıntılı, kesin bir "bulaşma göstergesi" listesi yok. Rapid7, kayıtlarda iz bulunmamasının sitenin güvenli olduğunu kanıtlamadığını belirtiyor. Yine de şu işaretler incelemeye değer:

• Olağandışı çok parçalı (multipart) isteklerin ardından gelen bellek sınırı hataları ya da tekrarlayan HTTP 500 yanıtları.
• Olağandışı büyüklükte PHPSESSID çerezleri.
• Açıklanamayan PHP işçi süreci yeniden başlatmaları.
• WordPress'te tanımadığınız yönetici hesapları, wp-content/uploads klasöründe .php dosyaları, beklenmedik zamanlanmış görevler.

Bellek sızıntısı olasılığı nedeniyle, bir saldırıdan şüpheleniyorsanız yönetici parolalarını, veritabanı parolasını ve API anahtarlarını yenilemek mantıklı. Bir güvenlik uzmanıyla çalışın ve sunucu kayıtlarını silmeyin.

Sık sorulan sorular

PHP2Shell WordPress eklentisi ya da teması mı?

Hayır. PHP'nin çalışma zamanındaki iki açığa verilen ad. Bu yüzden WordPress eklentileri güncellemek açığı kapatmaz.

PHP sürümüm 8.3 ama hosting sağlayıcım yamayı uyguladığını söylüyor. Güvende miyim?

Dağıtım yamaları sürüm numarasını değiştirmeden uygulanabilir. Yazılı teyit istemek ve CVE numaralarını sormak en güvenlisidir.

Güvenlik eklentisi (Wordfence vb.) beni korur mu?

Kısmen. Bir güvenlik duvarı bilinen saldırı imzalarını engelleyebilir, ancak saldırganların yüklerini korumaları atlatmak için değiştirdiği bildirildi. Güvenlik duvarı güncellemenin yerini tutmaz.

Cloudflare kullanıyorum, yeterli mi?

Cloudflare erken dönemde bu açığa karşı güvenlik duvarı kuralları devreye aldı, ancak saldırganlar bu kuralları atlatmaya çalıştı. Cloudflare önünüzde olması riski azaltır, ortadan kaldırmaz. Sunucudaki PHP'yi güncellemeniz gerekir.

PHP 7.4 ya da 8.0 kullanıyorum. Ne yapmalıyım?

Bu sürümler resmî güncelleme almıyor. Sağlayıcınızın yama taşıyıp taşımadığını sorun. Asıl çözüm desteklenen bir sürüme (8.3 ya da 8.4) geçmek. Eski PHP'ye bağlı eklenti ya da temalarınız varsa önce bir test ortamında deneyin.

PHP'yi güncellemek siteyi bozar mı?

Aynı dal içindeki yama sürümleri (ör. 8.3.12'den 8.3.36'ya) genellikle uyumluluk sorunu çıkarmaz. Dal değiştirmek (7.4'ten 8.3'e gibi) eski eklentilerde hata verebilir. Her durumda önce yedek alın ve kritik sayfaları güncelleme sonrası test edin.

Sonuç

PHP2Shell, bir eklenti açığından daha derin bir sorun: tüm sitenin altındaki zemin. Çözümü basit ama sizin kontrolünüzde olmayabilir, çünkü PHP'yi hosting sağlayıcısı yönetiyor. Bu yüzden ilk adım sürümünüzü öğrenmek, ikincisi sağlayıcıdan yazılı teyit almak. WordPress sitenizin bakımı, güvenliği ve hosting yönetimi konusunda destek isterseniz İzmir WordPress ajansı sayfamıza göz atabilir ya da bize ulaşabilirsiniz.

Kaynaklar:

• Qualys: PHP2Shell, iki kritik PHP açığı
• The Hacker News: PHP acil yamalar yayımladı
• Rapid7: CVE-2026-109618 ve CVE-2026-109619
• runZero: Etkilenen varlıkların tespiti
• NCSC (Birleşik Krallık): PHP'yi etkileyen kritik güvenlik sorunu