PHP, PHP2Shell RCE açıklarına yönelik acil yamaları yayınladı; uzmanlar istismar edilebilirliği tartışıyor

PHP, PHP2Shell için acil düzeltmeleri yayınladı

21 Ekim 2026'da PHP projesi, runtime'ın kendisindeki CVE-2026-109618 ve CVE-2026-109619 olarak takip edilen ve hızla PHP2Shell adı verilen iki açık için acil güvenlik sürümleri yayınladı. Sızma testi firması Raxis'in raporuna göre her iki hatanın CVSS v4.0 skoru 9.2 ve kimlik doğrulaması olmadan uzaktan kod çalıştırmaya (RCE) imkân veriyor. Açıklar PHP'nin kendisinde değil PHP üzerinde geliştirilen uygulamalarda değil de PHP'de bulunduğu için, kodu özenle denetlenmiş siteler bile risk altında.

Raxis'in aktardığı The Hacker News haberine göre, 5.4'e kadar geriye doğru neredeyse her PHP sürümü etkileniyor; Apache mod_php veya PHP-FPM çalıştıran sunucular da dahil. Mod_php en kötü senaryo, çünkü tek bir istek, herhangi bir uygulama kodu çalışmadan önce hatayı tetikleyebiliyor. Yama çıktığı sabah herkese açık bir sürüm denetleyici hazırlayan Kyle Clouthier'in dev.io'daki yazısına göre PHP'nin kılavuzu, etkilenenler arasında php-cgi, FrankenPHP ve LiteSpeed'i de sayıyor. Araştırmacılar ayrıca hataların canlı worker belleğini sızdırabildiğini gösterdi; bu da diğer kullanıcıların isteklerine ait şifreleri ve API anahtarlarını açıkta bırakabilir.

Yamadan önce istismar bildirimleri

The Hacker News'e göre Cloudflare, düzeltmeler herkese açık olmadan önce istismar denemeleri gözlemledi ve Raxis, acil yamalamaya çağıran bir CISA danışma belgesine dikkat çekiyor. Clouthier ise teknik ayrıntıların sürümden bir gün önce sızdığını, yama geldiğinde istismar kodunun zaten dolaşımda olduğunu ve Hollanda ile Finlandiya'daki devlet sitelerinin çoktan çevrimdışı kaldığını ekliyor. Hollanda ulusal CERT'i NCSC-NL, operatörler için bir kılavuz sayfası güncelliyor.

Neler kurulmalı ve restart tuzağı

Düzeltilmiş sürümler 8.2.35, 8.3.36, 8.4.27 ve 8.5.12. Raxis, her sunucuda php -v çalıştırıp listeyi karşılaştırmayı öneriyor; ama bir uyarıyla: Linux dağıtımları güvenlik düzeltmelerini eski sürüm dizesini koruyarak geri taşıyabiliyor, dolayısıyla paket changelog'unda CVE tanımlayıcılarını aramak daha güvenilir. Kendi PHP'sini paketleyen container ve cihazlar da kontrol edilmeli; paylaşımlı hosting müşterileri ise doğrudan sağlayıcılarına sormalı.

Paketi kurmak işin tamamı değil. Clouthier, PHP-FPM havuzları ile mod_php kullanan Apache'nin eski binary'yi restart edilene kadar bellekte tuttuğunu, ayrıca cPanel ve Plesk gibi kontrol panellerinin sık sık birden fazla PHP sürümünü yan yana çalıştırdığını, her birinin kendi güncellemesini gerektirdiğini vurguluyor. composer update burada hiçbir şey başarmaz, çünkü hata bağımlılıklarda değil runtime'ın kendisindedir.

Acil yamalamanın mümkün olmadığı yerlerde The Hacker News, session.upload_progress'i devre dışı bırakmak ve web sunucusu ya da proxy tarafında istek boyutu sınırlarını zorunlu kılmak gibi geçici önlemler anlatıyor. Bunlar maruziyeti azaltır ama kapatmaz; PHP'nin kendisi hiçbir yapılandırma değişikliğinin eksiksiz bir çözüm olmadığını söylüyor ve Cloudflare kendi koruma kurallarını geçici bir önlem olarak nitelendiriyor.

Ömrünü tamamlamış sürümlerin kuyruğu

Resmî düzeltme sürümleri yalnızca 8.2 ile 8.5 dalları için mevcut. Eski dallara paketlenmiş güncelleme gelmeyecek — Clouthier yalnızca PHP'yi kendisi derleyenler için asgari kaynak kodu yamaları olduğunu bildiriyor — ve PHP 8.2, 31 Aralık 2026'da ömrünü tamamlayacak; Raxis bu yüzden 8.3 veya daha yeni bir sürüme geçiş planlanmasını öneriyor. Kuyruk büyük: Detectify, PHP sitelerinin kabaca yarısının artık yama almayan sürümler çalıştırdığını tahmin ediyor ve Clouthier'in denetleyicisine ilk gün sürümünü gösteren 85 siteden 30'ı, kurulacak resmî bir şeyi olmayan ömrünü tamamlamış sürümlerdaydı.

Gerçekte ne kadar istismar edilebilir tartışması

Hacker News ana sayfasına ulaşan Elias Taylor'ın geniş biçimde paylaşılan blog yazısı, paniğe karşı çıkıyor. GitHub'da saatler içinde beliren binlerce proof-of-concept istismarın stok bir PHP kurulumunda başarısız olduğunu, birçoğunun ise önceden var olan bir local file inclusion zafiyetine bağlı olduğunu, yani hedefin zaten ikinci bir açık taşımayı fiilen gerektirdiğini belirtiyor. Bozuk istismar dalgasının kaynağı olarak LLM'lerle üretilmiş kodu gösteriyor ve hatanın Log4Shell ile kıyaslanamayacağını savunuyor; bir PHP çekirdek geliştiricisinin, yayından dakikalar içinde çalışan istismarlar öngörüsünün ilk saatlerde evrensel bir istismara dönüşmediğine dikkat çekiyor.

Anlatılar zorunlu olarak çelişmiyor: Cloudflare'nin telemetrisi ve kesinti raporları gerçek dünyada keşif denemeleri gösterirken, Taylor'ın savı değiştirilmemiş bir sunucyunun güvenilir biçimde istismarının CVSS skorunun ima ettiğinden daha zor olduğu yönünde. Her halükârda tüm kaynakların pratik önerisi aynı: yamala, restart et, doğrula.

Neden önemli

PHP2Shell, bir uygulamanın altındaki runtime'ın da saldırı yüzeyinin bir parçası olduğu ve bunu düzeltme sorumluluğunun uygulama geliştiricileri değil; hosting sağlayıcılarına, platform ekiplerine ve image bakımcılarına düştüğü hatırlatmasıdır. Ayrıca web'in ne kadar hâlâ hiç güvenlik sürümü almayan PHP dalları üzerinde çalıştığını ortaya koyuyor; bu da danışma belgesi ne kadar acil olsa da tam bir iyileştirmeyi olası kılmıyor. Son olarak olay, LLM çağında istismar istihbaratının ilk gerçek saha testi: çoğu çalışmayan binlerce inandırıcı görünümlü proof of concept, açıklamadan sonraki saatlerde içinde durumu bulandırabiliyor. Operatörler için hesap değişmedi: düzeltilmiş sürümü kur, her PHP worker'ını restart et ve hâlâ desteklenmeyen bir dalda olan her şeyin envanterini çıkar.