PHP'nin kendisindeki PHP2Shell açıkları için acil güncelleme yayımlandı, giriş yapmadan sunucuda kod çalıştırma girişimleri başladı

PHP geliştiricileri 21 Ekim’de, Türkiye saatiyle 17.00’de, PHP’nin çalışma motorundaki iki kritik açığı kapatan acil sürümler yayımladı. Açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarıyla izleniyor ve ikisi birlikte PHP2Shell olarak anılıyor. İkisinin de CVSS 4.0 puanı 9.2. Açıkları Wiz Research, Calif ve OpenAI’ın Codex Security ekibindeki araştırmacılar buldu.

Bu açıkları önemli kılan, bir eklentide ya da uygulamada değil PHP’nin kendisinde olmaları. The Hacker News’in aktardığına göre açıklar PHP 5.4’e kadar uzanan neredeyse bütün sürümleri etkiliyor ve sunucuda yalnızca “Merhaba Dünya” yazan bir sayfa bile saldırıya açık olabiliyor. PHP; WordPress, Joomla, Drupal gibi içerik yönetim sistemlerinin ve pek çok e-ticaret altyapısının altında çalışıyor. BleepingComputer’ın aktardığı VirusTotal tahminine göre internete açık 5,1 milyondan fazla PHP sunucusu var.

Açıkların işleyişi

BleepingComputer’ın aktardığına göre iki açığın kökü aynı: Bir istek beklenmedik biçimde sona erdiğinde PHP belleği bozuk bir durumda bırakabiliyor. CVE-2026-109618, bellek yetersizliği (out-of-memory) sırasında oluşan bozulmayı kullanan bir zincirle, sunucuda web servisinin yetkileriyle kod çalıştırmaya izin veriyor. CVE-2026-109619 ise PHP’nin bellekte eski ve geçersiz kalmış genel durum bilgisini (stale global state) kullanmaya devam etmesinden kaynaklanıyor, giriş yapmadan bellek okumaya ve kod çalıştırmaya imkân veriyor.

Kod çalıştırmanın yanı sıra bir saldırgan, PHP işçi sürecinin belleğini de okuyabiliyor. The Hacker News’e göre bu bellekte başka kullanıcıların isteklerine ait parolalar, oturum anahtarları, API anahtarları ve sertifikalar bulunabiliyor. Araştırmacılar bu bellek okumayı, kendilerine ait olmayan uygulamalara karşı da gösterdi.

Etkilenen kurulumlar

PHP’nin duyurusuna göre web isteklerini karşılayan bütün PHP kurulumları etkileniyor: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed.

PHP ekibi riski en yüksek gördüğü yapının Apache mod_php olduğunu söylüyor. Bu yapıda, giriş gerektirmeyen tek bir isteğin, uygulama kodu daha çalışmadan saldırıyı tetiklediği gösterildi. PHP-FPM’de durum biraz farklı. The Hacker News’in aktardığına göre CVE-2026-109618 için FPM’in de etkilendiği değerlendiriliyor ama FPM’de tam çalışan bir saldırı gösterilmedi. CVE-2026-109619 ise hem mod_php hem PHP-FPM’de kod çalıştırmaya ulaştı, ancak FPM’deki yol uygulamanın içindeki bir işleme bağlı. Bu ayrıntılar FPM kullananların beklemesi için bir gerekçe değil, PHP ekibi bütün kurulumların güncellenmesini istiyor.

Etkilenen ve düzeltilmiş sürümler

• PHP 8.5: 8.5.12 öncesi sürümler, düzeltilmiş sürüm 8.5.12
• PHP 8.4: 8.4.27 öncesi sürümler, düzeltilmiş sürüm 8.4.27
• PHP 8.3: 8.3.36 öncesi sürümler, düzeltilmiş sürüm 8.3.36
• PHP 8.2: 8.2.35 öncesi sürümler, düzeltilmiş sürüm 8.2.35

PHP 8.1 ve daha eski sürümler artık PHP projesinden güncelleme almıyor. PHP ekibi, açıkların ciddiyeti nedeniyle PHP 7.4, 8.0 ve 8.1 için kaynak koddan derleyenlere yönelik asgari düzeltmeler de yayımladı. PHP 8.2’nin desteği ise 31 Aralık 2026’da bitiyor.

Linux dağıtımları ve uzun süreli destek veren firmalar düzeltmeleri önceden aldı. Bu yüzden bir dağıtım paketi, eski görünen bir sürüm numarasıyla da düzeltmeyi içeriyor olabilir. The Hacker News’in Debian’a dayanarak aktardığı gibi, sürüm numarasına değil paketin değişiklik kaydında bu CVE numaralarının geçip geçmediğine bakmak gerekiyor.

Saldırı girişimleri

Saldırı girişimleri var, ancak bir sunucunun bu açıklarla ele geçirildiği henüz doğrulanmış değil. Cloudflare, güncelleme yayımlanmadan önce ilk saldırı girişimlerini gördüğünü açıkladı ve 21 Ekim’de Türkiye saatiyle 06.02’de müşterileri için varsayılan olarak açık güvenlik duvarı kuralları devreye aldı. Şirket, saldırganların bu kuralları aşmak için isteklerini değiştirdiğini de gözlemledi ve kuralların geçici bir önlem olduğunu vurguladı. Güvenlik şirketi watchTowr, 21 Ekim’de Türkiye saatiyle 17.19’da yayımladığı yeni bildirimde iki açık için de “aktif istismar girişimleri” gördüğünü bildirdi. 21 Ekim itibarıyla açıklar ABD siber güvenlik ajansı CISA’nın saldırılarda kullanılan açıklar listesi KEV’de değildi.

Birçok kurum önlem olarak hizmetlerini geçici olarak kapattı. The Hacker News’in Hollanda yayın kuruluşu NOS’a dayanarak aktardığına göre Hollanda’da DigiD ve MijnOverheid gibi kamu hizmetleri ile bazı eğitim sistemleri kapatıldı. İngiltere Ulusal Siber Güvenlik Merkezi NCSC de kurumlara PHP kullanan sistemleri hemen güncellemelerini ya da güncellenene kadar erişime kapatmalarını tavsiye etti.

Türkiye’de Siber Güvenlik Başkanlığı’nın uyarısı

Siber Güvenlik Başkanlığı 21 Ekim’de TR-26-1372 numaralı güvenlik bildirimini yayımladı. Başkanlık ayrıca yaptığı duyuruda, zafiyetlerin oluşturabileceği risklerin erken tespiti için “ulusal ölçekte güvenlik taramalarını” başlattığını ve ilgili kurum ve kuruluşlara acil güvenlik bildirimleri ilettiğini açıkladı. Başkanlık kurumlara şu adımları öneriyor:

• Etkilenen sistemlerin belirlenmesi ve üreticinin yayımladığı güvenli sürümlere gecikmeden yükseltilmesi
• Yönetim arayüzlerine ve kritik PHP servislerine dışarıdan erişimin, güvenlik duvarı kurallarıyla yalnızca güvenilir IP adreslerine sınırlandırılması
• “Yurt dışı erişim ihtiyacı bulunmayan sistemlerin ivedilikle uluslararası trafiğe kapatılması”

Açıkların ortaya çıkışı

Açıkların 22 Ekim’de duyurulması planlanıyordu, ancak bilgi önceden sızdı. 20 Ekim’de Hacker News forumunda, iki PHP açığının CVE numaralarıyla 22 Ekim’de duyurulacağını iddia eden bir paylaşım yapıldı. PHP aynı akşam ön duyuru yayımlayıp güncellemeyi 21 Ekim’e çekti. Paylaşımda açıklara 10 puan verildiği iddia ediliyordu, ancak PHP’nin verdiği puan 9.2.

PHP Foundation’ın açıklamasına göre koordineli duyuru süreci yayımdan önce dağıldı. Calif, 20 Ekim’de Türkiye saatiyle 23.00 civarında çalışan saldırı kodunun videosunu yanlışlıkla paylaştı. 21 Ekim’de Türkiye saatiyle 10.41’de, yani güncellemeden yaklaşık altı saat önce, yazılım firması Chainguard düzeltmeyi içeren imajlarını yayımladı. Bu da düzeltmenin herkesçe incelenebilmesine yol açtı.

PHP Foundation, bellek yetersizliğiyle ilgili açığın ilk işaretlerinin 2024’teki dış güvenlik denetiminde bir çekirdek geliştirici tarafından fark edildiğini, ancak o zaman kod çalıştırmaya giden somut bir yol bulunamadığını da açıkladı. Vakıf, düzeltme çalışmalarının aylarca durmasını karar süreçlerindeki “yapısal bir başarısızlık” olarak nitelendirdi. Araştırmacılar, yapay zekâ modellerinin uzun süredir kodda duran bu hataları çalışan saldırılara dönüştürmede kendilerine büyük hız kazandırdığını söylüyor.

Önerilen önlemler

PHP’yi güncelleyin. Sunucunuzu kendiniz yönetiyorsanız işletim sisteminizin PHP paketlerini güncelleyin ve paket değişiklik kaydında CVE-2026-109618 ile CVE-2026-109619’un geçtiğini kontrol edin. Konteyner kullanıyorsanız temel imajı güncelleyip konteynerleri yeniden oluşturun. Paylaşımlı hosting kullanıyorsanız hosting firmanızın güncellemeyi yapıp yapmadığını sorun. PHP sürümünü panelden seçebiliyorsanız desteklenen ve düzeltilmiş bir sürüme geçin.

Güncellemeden sonra servisleri yeniden başlatın. Apache, PHP-FPM ve sürekli çalışan bütün PHP işçileri yeniden başlatılmadan eski kod bellekte çalışmaya devam eder. WordPress, Laravel gibi uygulamaları güncellemek PHP’yi güncellemez.

Hemen güncelleyemiyorsanız PHP ekibinin önerdiği ayarlar bazı saldırı yollarını kapatıyor, ama sunucuyu güvenli hâle getirmiyor:

• CVE-2026-109618 için memory_limit=-1 ayarını uygulamaların değiştiremeyeceği biçimde (örneğin FPM havuzunda ya da Apache yapılandırmasında php_admin_value ile) verin, post_max_size değerini düşük tutun (dosya yükleme gerekmiyorsa 8M, gerekiyorsa 32M) ve istek boyutunu web sunucusu ya da vekil sunucu katmanında sınırlayın. Bellek sınırı için RLIMIT_AS ya da RLIMIT_DATA kullanmayın, PHP bunların aynı açık yolu tetikleyebileceği konusunda uyarıyor.
• CVE-2026-109619 için session.upload_progress.enabled=0 yapıp bütün işçileri yeniden başlatın. PHP 8.5 kullanıyorsanız fatal_error_backtraces=0 ayarını da verin. Bu ayarlar doğrulanmış saldırı yollarını kapatıyor, diğer varyantları değil.

Güncellemeden önce geçici çözüm olarak paylaşılan session.upload_progress.enabled=0 ayarının tek başına yeterli olmadığı, PHP’nin yayımıyla doğrulandı. PHP çekirdek geliştiricisi Gina Peter Banyard da tek gerçek önlemin güncelleme olduğunu vurguladı.

Güncellemeden sonra bellek ayarlarınızı gözden geçirin. Düzeltme yeni bir kesin bellek sınırı getiriyor. Bu sınıra ulaşıldığında süreç sonlandırılıyor ve kapanış işlemleri çalışmıyor. memory_limit ve post_max_size değerlerinin uygulamanızın ihtiyacına uygun olduğunu kontrol edin.

Daha önce bir saldırı olup olmadığına bakın. Araştırmacılar, kayıtlarda ardından bellek sınırı hataları ya da tekrarlanan HTTP 500 yanıtları gelen olağandışı multipart istekleri, alışılmadık büyüklükte PHPSESSID çerezleri ve PHP işçilerinin açıklanamayan yeniden başlamalarını işaret olarak gösteriyor. Açıklar işçi belleğinin okunmasına da izin verdiği için, şüpheli bir iz bulursanız PHP uygulamalarınızın kullandığı veritabanı şifrelerini ve API anahtarlarını değiştirmeniz yerinde olur.