PHP2Shell: WordPress site sahipleri şimdi ne yapmalı?
PHP2Shell (CVE-2026-109618, CVE-2026-109619) yamasız PHP'de kod çalıştırmaya izin verir. Sürümünüzü kontrol edin, güncelleyin, yeniden başlatın, izleyin.
Diğer diller: English Deutsch Français Español Italiano Polski Português
PHP2Shell, PHP'nin kendisinde bulunan iki kritik güvenlik açığının adıdır. Açıklar 21 Ekim 2026'da duyuruldu ve CVSS puanı 9,2 olarak belirlendi. Yamalanmamış bir PHP çalışma ortamında, hesabı olmayan bir saldırgan sunucuda kod çalıştırabilir ya da parolaların, oturum belirteçlerinin ve API anahtarlarının bulunduğu belleği okuyabilir. Araştırmacılar saldırıyı güncel WordPress kurulumları üzerinde gösterdi. WordPress'i, temanızı ya da eklentilerinizi güncellemek sorunu çözmez: sitenizin altında çalışan PHP sürümünün güncellenmesi gerekir.
Bu rehberde PHP2Shell'in ne olduğunu, sitenizin etkilenip etkilenmediğini nasıl kontrol edeceğinizi, barındırma firmanıza ne sormanız gerektiğini ve güncelleme bugün yapılamıyorsa ne yapabileceğinizi bulacaksınız.
PHP2Shell nedir?
Wiz Research, OpenAI Codex Security ve Calif'in araştırması, PHP motorunda birbiriyle bağlantılı iki tür bellek güvenliği hatası ortaya çıkardı:
- CVE-2026-109618, bellek tükendiğinde durum bozulması. PHP'nin belleğin tükenmesini ele alış biçimi, iç durumunu bozabilir. Bir saldırgan bunu, oturum açmadan PHP web işçi süreci (worker) olarak kod çalıştırmak için kullanabilir.
- CVE-2026-109619, istekler arasında kalan eski genel durum. Bir isteğe ait veriler bir sonraki isteğe kadar yaşamaya devam edebilir. Bu da işçi sürecin belleğini sızdırabilen ya da kod çalıştırmaya imkân veren bir use-after-free hatasına yol açar.
Açık PHP'nin kendisinde olduğu için sizin kodunuzun hata içermesi gerekmez. Araştırmacılara göre etkilenen bir PHP sürümündeki "Hello World" sayfası bile risk altında olabilir. WordPress, Drupal ve Joomla, araştırmacıların kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırmayı göstermek için kullandığı uygulamalardan ibaretti. PHP ekibi düzeltilmiş sürümleri aynı gün yayımladı.
Bir WordPress sitesi için en önemli iki sonuç şunlardır:
- Sunucunun ele geçirilmesi. PHP işçi süreci olarak kod çalıştırmak, genellikle saldırganın dosyaları değiştirebileceği, yönetici ekleyebileceği, arka kapı yerleştirebileceği ya da veritabanına ulaşabileceği anlamına gelir.
- Sessiz veri hırsızlığı. Bellek sızıntısı zararlı kod çalıştırmadan işler, bu yüzden çok az iz bırakabilir. Yoğun çalışan bir PHP işçi sürecinin belleğinde diğer ziyaretçilerin parolaları ve çerezleri, veritabanı parolanız ve API anahtarlarınız bulunabilir.
Sitem etkileniyor mu?
PHP'niz 21 Ekim 2026'da veya sonrasında güncellenmediyse neredeyse kesinlikle evet. Araştırmacılar PHP 5.4'e kadar uzanan etkilenmiş sürümler buldu. Desteklenen her dal için ilk düzeltilmiş sürümler şunlardır:
| PHP dalı | Açık bulunan | İlk düzeltilmiş sürüm |
|---|---|---|
| 8.2 | 8.2.35 öncesi | 8.2.35 |
| 8.3 | 8.3.36 öncesi | 8.3.36 |
| 8.4 | 8.4.27 öncesi | 8.4.27 |
| 8.5 | 8.5.12 öncesi | 8.5.12 |
PHP 8.1, 8.0 ve tüm 7.x sürümleri artık PHP projesi tarafından desteklenmiyor ve bu tabloda yer almıyor. Siteniz bunlardan birinde çalışıyorsa kurabileceğiniz düzeltilmiş bir sürüm yoktur: desteklenen bir dala geçmeniz gerekir.
WordPress'te tam sürümünüzü görmek için Araçlar → Site Sağlığı → Bilgi sayfasını açın ve Sunucu bölümünü genişletin. "PHP sürümü" satırı tam numarayı gösterir, örneğin 8.3.36. İlk iki kısım (8.3) yeterli değildir: önemli olan son sayıdır.
Nasıl düzeltilir?
Tek tam çözüm, yamalanmış bir PHP çalışma ortamı ve ardından yeniden başlatmadır.
- Her çalışma ortamında PHP'yi güncelleyin. Kendi sunucunuzda, dağıtımınızın güncellenmiş paketlerini yayımlanır yayımlanmaz ya da php.net adresindeki resmi sürümü kurun. Yönetilen veya paylaşımlı barındırmada PHP'yi barındırma firması günceller; paketinizin düzeltilmiş sürümle çalışıp çalışmadığını doğrudan firmaya sorun.
- PHP'yi yeniden başlatın. Yeni bir PHP paketi, çalışan süreçler değiştirilene kadar hiçbir işe yaramaz. PHP-FPM'yi, mod_php kullanan Apache'yi ve uzun süre çalışan tüm PHP işçi süreçlerini yeniden başlatın.
- Sonucu kontrol edin. Site Sağlığı ekranına tekrar bakın. PHP sürümü artık dalınızın düzeltilmiş sürümüne eşit veya ondan yüksek olmalıdır.
- Diğer çalışma ortamlarını unutmayın. Test (staging) siteleri, barındırma panelinizde seçili ikinci bir PHP sürümü, cron işleri ve WP-CLI için kullanılan PHP ve konteyner imajları da hesaba katılmalıdır.
Barındırma panelinizde bir PHP sürüm seçici varsa, "8.3" ya da "8.4" seçmek ancak barındırma firması bu etiketin arkasına yamalı derlemeyi zaten kurmuşsa güvenlidir. Gerçeği Site Sağlığı ekranı söyler.
Bugün güncelleyemiyorsanız
Araştırmacılar geçici önlemler sıralıyor. Her biri bazı saldırı yollarını engeller, hiçbiri hepsini engellemez ve bazıları sitenizi etkileyebilir; bu yüzden önce test edin:
- PHP sürümünüz destekliyorsa
fatal_error_backtraces = 0. post_max_sizevemax_input_nesting_leveldeğerlerini formlarınızın ve dosya yüklemelerinizin izin verdiği ölçüde düşürün; yükleme ilerlemesini kullanan bir şey yoksasession.upload_progress.enabled = 0olarak ayarlayın.- Daha düşük bir
pm.max_requestsdeğeriyle PHP-FPM işçi süreçlerini daha sık yenileyin (bunun performans bedeli vardır). memory_limit = -1, bazı saldırıların dayandığı bellek sınırı yolunu ortadan kaldırır, ancak bellek tükenmesini işletim sistemine bırakır. Bunu yalnızca cgroup v2memory.maxgibi işletim sistemi düzeyinde bir sınırla birlikte kullanın ve aslaRLIMIT_ASya daRLIMIT_DATAile değiştirmeyin; PHP güvenlik duyurusuna göre bunlar aynı hatayı tetikleyebilir.
PHP hatalarını gizlemek (display_errors, error_reporting veya @) bu önlemlerden biri değildir: PHP projesi bunun işe yaramadığını söylüyor.
Güvenlik duvarı ve CDN sağlayıcıları PHP2Shell için kurallar yayımladı. Bu kurallar riski azaltabilir, ancak araştırmacılar koruyucu bir kuralın PHP güncellemesinin yerini tutmadığını açıkça belirtiyor.
Dikkat etmeniz gereken belirtiler
Tek bir log kaydı saldırıyı kanıtlamaz. Araştırmacılar incelenmeye değer sinyaller sayıyor: yanıtlarda olağandışı büyük veya bozuk PHPSESSID çerezleri, ardından bellek sınırı hataları ya da art arda HTTP 500 yanıtları gelen tuhaf multipart istekler ve sebepsiz yere çöken veya yeniden başlayan PHP işçi süreçleri. Bu sinyallerin olmaması sitenizin temiz olduğunu kanıtlamaz, çünkü bellek sızıntısı WordPress log kayıtlarında hiçbir iz bırakmayabilir.
Bu belirtileri görürseniz durumu olası bir güvenlik olayı olarak ele alın. Hacklenmiş bir WordPress sitesinin belirtileri rehberimiz ilk kontrollerde yardımcı olur. Sızan bellek gizli bilgiler içerebileceği için, yamayı uyguladıktan sonra veritabanı parolasını, wp-config.php içindeki anahtarları ve salt değerlerini ve tüm API anahtarlarını değiştirin. Kişisel verilerin açığa çıkmış olma ihtimali varsa GDPR süresi işlemeye başlar: 72 saatlik ihlal bildirimi rehberimize göz atın.
Nereden başlamalı?
- Araçlar → Site Sağlığı → Bilgi → Sunucu bölümünü açın ve yönettiğiniz her sitenin tam PHP sürümünü not edin.
- Bunu yukarıdaki tabloyla karşılaştırın. Düzeltilmiş sürümün altındaki her şey ya da PHP 8.1 veya daha eski bir sürüm bugün müdahale gerektirir.
- PHP'yi güncelleyin ya da barındırma firmanızdan yamalı sürümü isteyin, ardından PHP-FPM'nin veya Apache'nin yeniden başlatıldığından emin olun.
- Site Sağlığı ekranını tekrar kontrol edin ve ekran görüntüsünü düzeltmenin kanıtı olarak saklayın.
- Log kayıtlarınızı yukarıdaki belirtiler açısından inceleyin ve bir şey yolunda görünmüyorsa gizli bilgileri yenileyin.
Kaynaklar: php2shell.com, PHP Foundation duyurusu, Wiz Research.
Kendi sitenizi kontrol edin
Security Audit & Compliance, secaudit.eu’nun WordPress eklentisidir: zararlı yazılımları, gizli spam’i, değiştirilmiş çekirdek dosyalarını ve açıklı kodu tarar; bulguları GDPR Md. 32, NIS2 Md. 21 ve OWASP Top 10 ile eşleştirir.
Eklentinin neleri kontrol ettiğini görün