PHP2Shell (CVE-2026-109618 ve CVE-2026-109619): Kritik PHP RCE Açığı ve Korunma Rehberi

• PHP2Shell bir ürün değil; PHP çekirdeğindeki iki kritik RCE açığının ortak adıdır.
• CVE-2026-109618: bellek bozulmasına (OOM/Zend motoru) dayalı RCE. CVE-2026-109619: eski küresel durum (stale global state) üzerinden RCE; bir saldırı yolu session.upload_progress ile ilişkilidir.
• PHP ekibi 21 Ekim 2026'da yamaları yayımladı: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35.
• Yamalama her şeyin önündedir. Geçici önlemler (session.upload_progress kapatma, WAF kuralı) yamayı geciktiremediğiniz durumlar içindir, kalıcı çözüm değildir.

PHP2Shell nedir?

PHP2Shell, PHP programlama dilinin çekirdeğinde bulunan iki ayrı güvenlik açığına verilen isimdir. Açıklar PHP'nin kendisinde olduğu için, PHP ile çalışan WordPress, Drupal, Joomla ve özel yazılımlar dâhil çok geniş bir yüzey etkilenir. En tehlikeli yanı, saldırının kimlik doğrulaması gerektirmemesidir: saldırganın geçerli bir kullanıcı hesabına ihtiyacı yoktur.

Başarılı bir istismar, saldırgana sunucuda komut çalıştırma (RCE) imkânı verir. Buradan dosya okuma, veri sızıntısı, yeni kullanıcı açma ve fidye yazılımı için zemin hazırlama gibi adımlar gelebilir. PHP2Shell'in 'kritik' sayılmasının nedeni budur.

İki açık: CVE-2026-109618 ve CVE-2026-109619

PHP projesi her iki açığı CVSS v4.0'da 9.2 (kritik) olarak derecelendirdi. İstismar durumu kaynağa ve tarihe göre değişiyor. CrowdStrike 23 Ekim 2026'da yalnızca deneme ve başarısız girişimler gördüğünü yazdı. Palo Alto Networks Unit 42 ise 29 Ekim 2026'da internete açık PAN-OS yönetim arayüzlerine karşı aktif istismar bildirdi. Bu nedenle yamayı bekletmeyin.

Etkilenen ve yamalı sürümler

• Risk altındakiler: web isteği işleyen tüm PHP kurulumları. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed bu kapsamdadır. PHP ekibi en yüksek riskin mod_php'de olduğunu belirtir.
• Yamalı sürümler (21 Ekim 2026): PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35.
• PHP 8.1 ve öncesi ömrünü tamamlamıştır (EOL); PHP projesinden resmî sürüm almaz. PHP güvenlik ekibi 7.4, 8.0 ve 8.1 için sınırlı kaynak yamaları yayımlamıştır. PHP 8.2 de 31 Aralık 2026'da EOL olur.
• Dağıtım paketleri ayrı bir hat izler. Örneğin Debian ve Ubuntu paketleri, yukarı akış sürüm numarasından farklı bir sürümle yamayı geri taşıyabilir.
• Bu yüzden yalnızca yukarı akış numarasına değil, kendi dağıtımınızın paket sürümüne bakın.

Öncelik 1: Yamalayın

• Çalışan PHP sürümünü ve nasıl çalıştığını (mod_php, PHP-FPM, CLI) belirleyin.
• Dağıtımınızın yamalı paketini kurun ve ardından PHP-FPM veya web sunucusunu yeniden başlatın.
• Konteyner imajlarını yamalı temel imajdan yeniden oluşturun. Yalnızca çalışan konteyneri yamalarsanız imaj açık kalır.
• Birden fazla PHP sürümü barındıran sunucularda hepsini ayrı ayrı güncelleyin.
• EOL sürümdeyseniz desteklenen bir sürüme geçiş planı yapın; kaynak yamaları yalnızca geçici bir köprüdür.

Geçici önlemler (yama öncesi köprü)

• CVE-2026-109618: memory_limit=-1 yapın. Bunu uygulamanın değiştiremeyeceği bir yerde ayarlayın (örneğin php_admin_value). Bu önlem, alttaki bellek ayırma hatalarını engellemez.
• CVE-2026-109618: post_max_size değerini düşürün. Dosya yükleme yoksa 8M, varsa 32M kullanın. upload_max_filesize değerini post_max_size altında tutun.
• RLIMIT_AS veya RLIMIT_DATA kullanmayın. Bu sınırlar açığı tetikleyen bellek hatasına yol açabilir. Bunun yerine konteyner veya cgroup sınırı kullanın.
• CVE-2026-109619: php.ini, FPM havuzu veya sunucu yapılandırmasında session.upload_progress.enabled=0 yapın (ini_set() veya FPM .user.ini ile değil) ve tüm worker'ları yeniden başlatın. Bu, doğrulanmış oturum yollarını engeller, diğer varyantları engellemez.
• CVE-2026-109619: PHP 8.5'te fatal_error_backtraces=0 yapın ve tüm worker'ları yeniden başlatın.
• Saldırganın tetikleyebileceği ölümcül hataları ve yürütme zaman aşımlarını düzeltin.
• Web sunucusu, proxy veya WAF üzerinde istek boyutu, alan sayısı, multipart parça sayısı, başlık sayısı ve iç içe geçme derinliği sınırları koyun. PHP_SESSION_UPLOAD_PROGRESS içeren multipart POST isteklerini sınırlayabilirsiniz.
• Bu önlemleri önce test ortamında deneyin. PHP ekibine göre bu önlemler riski azaltır, ancak kurulumu güvenli yapmaz.

Ayrı konu: CVE-2026-115560

PHP ekibi 23 Ekim 2026'da bu açık için bilgilendirme yayımladı. 21 Ekim sürümleri bu açığı kapatmaz. Açık yalnızca şu durumda oluşur: uygulama session.serialize_handler değerini php_binary veya php_serialize olarak ayarlar, çalışma anında ini_set() ile php yapar ve session upload progress açıktır. Bu yapıyı kullanıyorsanız session.upload_progress.enabled=0 yapın. PHP ekibi tam bildirimi sonraki düzenli sürümle yayımlayacağını belirtti.

Tespit: istismar edilip edilmediğinizi nasıl anlarsınız?

Bellek bozulmasına dayalı istismar, hedef süreçte çökme ve yeniden başlamalara yol açabilir. Katmanlı tespit önerilir:

• Süreç davranışı: PHP-FPM veya web sunucusu sürecinin kabuk, ağ tarama veya şifreleme aracı başlatması güçlü bir alarmdır.
• Çökme ve segfault kayıtları: Web sunucusunda ani ve tekrarlayan segfault/çökme kayıtları incelenmelidir.
• Dosya bütünlüğü: Web kök dizininde beklenmedik yeni veya değişen dosyalar uyarı üretmelidir.
• Erişim kayıtları: PHP_SESSION_UPLOAD_PROGRESS alanı içeren olağan dışı multipart istekleri ve bilinmeyen dosyalara gelen kısa tekrarlı istekler aranmalıdır.
• Giden trafik: Sunucudan beklenmedik dış bağlantılar veri sızıntısına işaret edebilir.

Moftgate bu açığa karşı nasıl yardımcı olur?

Moftgate yamanın yerini tutmaz; önce PHP'yi güncellemeniz gerekir. Ancak Moftgate uç nokta ajanı, sunucular dâhil uç noktalarda süreç davranışını ve dosya değişikliklerini sürekli izler; böylece bir istismar denemesini erken yakalamanıza yardım eder. PHP-FPM sürecinin anormal bir komut başlatması veya web kök dizinine beklenmedik bir dosya yazılması merkezi konsolda alarm üretir. Yerleşik WORM yedekleme, saldırı fidye aşamasına geçerse verinin değiştirilemez bir kopyasını korur. DLP motoru ise elde edilen erişimle veri dışarı taşınmaya çalışıldığında çıkışı engeller.