PHP2Shell nedir, açık nasıl çalışıyor?

PHP2Shell, PHP’nin kendisinde bulunan ve 21 Ekim 2026’da yamalanan iki kritik açığa (CVE-2026-109618 ve CVE-2026-109619) verilen ad. Aynı gün Hollanda hükümeti DigiD’yi (vatandaşların devlet hizmetlerine girdiği kimlik sistemi) ve MijnOverheid’ı kendi isteğiyle kapattı. Meclisin ve ulusal siber güvenlik merkezi NCSC’nin siteleri de kapandı. Ortada bilinen bir saldırı yoktu; sebep, aynı gün yamalanacak iki PHP açığıydı.

İki açık da üzerine yazılan uygulamada değil, dilin çalışma zamanında. İkisi de CVSS 4.0’da 9,2 puan aldı ve bazı kurulumlarda giriş yapmamış birinin tek bir HTTP isteğiyle sunucuda kod çalıştırmasına izin veriyor. Düzeltilmiş sürümler (8.5.12, 8.4.27, 8.3.36 ve 8.2.35) 21 Ekim 14:00 UTC’de çıktı.

Duyuru aslında 22 Ekim’e planlanmıştı. Huntress’in aktardığına göre 20 Ekim sabahı açıkların varlığı Hacker News’teki bir gönderiyle sızınca PHP ekibi sürümü bir gün öne çekti. Türkiye’de Siber Güvenlik Başkanlığı da 21 Ekim’de TR-26-1372 kodlu bildirimle ulusal çapta tarama başlattı.

Sonraki saatlerde liste uzadı. Fransa, Danimarka ve Finlandiya’da devlet siteleri geçici olarak kapandı, Kanada da bazı federal sitelerini kapattı. Japonya’da ANA, JR West ve MUFG bankası bazı sayfalarını ya da hizmetlerini durdurdu; Wikimedia da bazı sistemlerini önlem olarak kapattı.

Açığı yapay zekâ mı buldu?

Kısmen. Açıkları Wiz’in araştırma ekibi buldu; yazıda PHP ekibine, Calif’e ve OpenAI’a keşif, koordinasyon ve yamanın doğrulanmasındaki katkıları için teşekkür ediliyor. Wiz çalışma boyunca kendi aracı Wiz Atlas’ı, Gemini 4 Argon’u ve GPT-5.6 Sol’u kullandığını, Gemini’nin açığın bulunmasına büyük katkı verdiğini yazıyor. Modeller exploit’i farklı PHP sürümlerine, ayarlara ve bellek düzenlerine uyarlamakta da kullanılmış.

Zaman çizelgesi de dikkat çekici. İlk açık 19 Ağustos’ta bulunmuş, iki gün içinde Drupal ve WordPress’te giriş gerektirmeyen kod çalıştırma doğrulanmış ve 24 Ağustos’ta PHP ekibine bildirilmiş. Wiz’e göre açıklı kod on yıldan uzun süredir PHP’deydi ve 5.4’e kadar geriye giden sürümler etkileniyor.

Wiz’in altını çizdiği nokta da bu: böyle bir hatayı çalışan bir saldırıya dönüştürmek eskiden çok emek isteyen bir işti ve modeller bu engeli ciddi biçimde düşürdü. Ajanlara Ghidra gibi tersine mühendislik araçlarını bağlayan REA da bu yönde bir araç.

Açık nasıl çalışıyor?

PHP’nin klasik modelinde her istek sıfırdan başlar: betik çalışır, cevap döner, isteğe ait her şey silinir. Ama istekleri karşılayan süreç silinmez. PHP-FPM’de ya da Apache mod_php’de aynı işçi süreç (worker) yüzlerce isteği art arda işler ve her isteğin sonunda belleği temizleyip bir sonrakine hazırlanır. İki açık da bu temizliğin varsayımlarını bozuyor.

CVE-2026-109619’da isteğe ait bir iç durum, gösterdiği bellek serbest bırakıldıktan sonra da yerinde kalıyor. Aynı işçinin aldığı bir sonraki istek, bu durum sıfırlanmadan önce onu kullanabiliyor. Bu klasik bir use-after-free: artık başka bir şeye ait olabilecek bir bellek bölgesine eski bir adresle dokunmak. Saldırgan o bölgeyi kendi isteğiyle doldurabilirse okunan veri de, çalışan kod da onun olur.

CVE-2026-109618’de PHP, istek verisini hazırlarken bellek sınırına takılıp yarıda kesiliyor. İsteğin sonundaki temizlik, yarım kalmış bu veriyi geçerli sanıp üzerinde işlem yapıyor.

Asıl ürkütücü kısım şu: php.net’in duyurusuna göre mod_php’de gösterilen istismar, uygulama kodu hiç çalışmadan tetikleniyor. WordPress’i, eklentileri ya da framework’ü güncellemek bir şey değiştirmiyor; kodunun ne kadar temiz olduğu da. Açık, kodunu çalıştıran şeyin içinde. Önerilen geçici ayarların (post_max_size, session.upload_progress) hepsinin isteğin gövdesi okunurken devreye girmesi de bunu destekliyor.

Ne yapmalı?

Tek gerçek çözüm güncellemek. PHP’nin sürüm notları tam bir geçici çözüm olmadığını açıkça söylüyor. Önerilen ayarlar (memory_limit, post_max_size, session.upload_progress.enabled = 0) yalnızca bazı saldırı yollarını daraltıyor ve uygulamanın ezemeyeceği yerde, örneğin php_admin_value ile verilmeleri gerekiyor.

• 8.2 ile 8.5 arasındaysan yukarıdaki sürümlere geç. 8.2’nin desteği 31 Aralık 2026’da bitiyor.
• 8.1 ve öncesi PHP ekibinden güncelleme almıyor. 7.4, 8.0 ve 8.1 için yalnızca küçük kaynak yamaları yayımlandı; dağıtımının ya da hosting firmanın bunları uygulayıp uygulamadığına bak.
• Sürümü kontrol ederken php -v’ye güvenme. Komut satırındaki PHP ile web sunucusunun kullandığı PHP-FPM ya da mod_php farklı kurulumlar olabilir; php-fpm -v ya da geçici bir phpinfo() sayfası (işin bitince sil) gerçek sürümü gösterir.
• Güncellemeden önce saldırıya uğramış olabilirsin. Huntress’in önerisi, php-fpm ya da httpd sürecinin altından sh, bash, curl, wget gibi süreçlerin başladığı anlara bakmak; web klasöründe yeni dosya, yeni cron işi ve yeni kullanıcı aramak.

Siten paylaşımlı hosting’deyse PHP’yi sen değil firma günceller. Panelden sürümü kontrol etmek yine senin işin.