PHP, dilin kendisinde bulunan iki kritik açığı kapatan acil güncellemeler yayınladı; bu açıklar hesabı olmayan bir saldırganın web sunucusunda kod çalıştırmasına izin veriyor. Düzeltmeler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde yer alıyor ve PHP ekibi sunucuyu tamamen korumak için yalnızca güncellemenin yeterli olduğunu belirtiyor.
Açıklar birlikte PHP2Shell olarak adlandırılıyor ve bir uygulamada değil PHP çalışma zamanında bulunuyor, bu yüzden sitenin kendi kodu güvenli olsa bile sistem açık kalıyor. Risk, Apache’nin mod_php kullanan sunucularda en yüksek; çalışan bir istismar, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikliyor.
Her iki açık da CVSS v4.0 ölçeğinde 9,2 olarak derecelendirildi ve CVE-2026-109618 ile CVE-2026-109619 tanımlayıcılarını taşıyor. PHP bunları 21 Ekim’de planlanan yayın saati olan 14:00 UTC civarında duyurdu; bu, planlanan 22 Ekim açıklamasından bir gün önce ayrıntıların sızdırılmasının ardından gerçekleşti.
Wiz, Calif ve OpenAI araştırmacıları açıkları bulup bildirdi; açıklar PHP 5.4’e kadar neredeyse her PHP sürümünü etkiliyor.
Kimler etkileniyor
PHP güvenlik duyurusuna göre web isteği sunan her PHP kurulumu risk altında; bu kapsamda PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed bulunuyor.
Açıklar motorun kendisinde olduğu için sitenin koduyla ilgisi yok; savunmasız bir PHP sürümünde çalışan basit bir "Hello World" sayfası bile saldırıya uğrayabilir.
Duyuru en yüksek riski mod_php olarak vurguluyor; gösterilen bir istismarda tek bir kimliği doğrulanmamış istek, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikliyor. PHP-FPM farklı davranıyor çünkü istek kurulumun erken aşamasında başarısız olunca çalışanı kapatıyor.
İki açıktan biri için PHP’nin kendi analizi FPM’nin savunmasız olduğunu destekliyor ancak tam bir FPM istismarının gösterilmediğini söylüyor; ikinci açık hem mod_php hem de PHP-FPM üzerinde kod çalıştırma sağlaması gösterildi, FPM yolunda ise çalışan uygulama içindeki bir işlem gerekiyor.
Saldırgan, kod çalıştırmadan önce PHP çalışan işleminden bellek okuyabiliyor; bu bellekte diğer isteklerin parolaları, kimlik doğrulama belirteçleri, API anahtarları ve sertifikaları bulunabiliyor.
Araştırmacılar bu canlı çalışan bellek okumasını kontrol etmedikleri uygulamalara karşı göstererek bunun üstteki uygulamanın bağımsız olduğunu kanıtladı.
Ne kurulmalı
Web isteklerini sunan PHP çalışma zamanını güncelleyin, ardından Apache, PHP-FPM ve uzun süre çalışan PHP çalışanlarını yeniden başlatın. WordPress veya Laravel gibi bir uygulamayı güncellemek alttaki PHP çalışma zamanını güncellemiyor; bu, sunucu paketi, barındırıcı veya kapsayıcı imajından geliyor.
İlk düzeltilen sürüm
PHP 8.1 ve daha eski sürümler PHP projesinden artık güncelleme almıyor ve PHP 8.2, 31 Aralık 2026’da yaşam sonuna ulaşıyor. Daha eski dallar için PHP güvenlik ekibi, kaynak koddan derleyenler veya satıcı bekleyenler için PHP 7.4, 8.0 ve 8.1 için kaynak geri portları yayınladı.
Linux dağıtımları ve uzun süreli destek satıcıları yamaları önceden aldı, bu yüzden bir dağıtım paketi eski görünümlü bir sürüm numarası altında düzeltmeyi taşıyabiliyor; Debian’ın da önerdiği gibi sürüm dizesine değil paket günlüğünde CVE’ye bakın.
Henüz güncelleyemiyorsanız
Tek başına güncelleme tam bir çözümdür. Aşağıdaki önlemler belirli saldırı yollarına karşı riski azaltır ve duyuruya göre sunucuyu güvenli hale getirmez.
CVE-2026-109618 için memory_limit=-1 ayarlayın böylece uygulamalar bunu geçersiz kılamasın, post_max_size değerini düşük tutun ve web sunucusu veya proxy’de istek boyutu sınırları uygulayın. RLIMIT_AS veya RLIMIT_DATA’yı ikame olarak kullanmayın; PHP bunların aynı savunmasız yolu tetikleyebileceği konusunda uyarıyor.
CVE-2026-109619 için session.upload_progress.enabled=0 ayarlayın ve her çalışanı yeniden başlatın; PHP 8.5’te ayrıca fatal_error_backtraces=0 ayarlayın. Oturum yükleme ilerlemesini kapatmak onaylanmış oturum yollarını engeller ancak diğer varyantları engellemez ve güncelleme dışında tam bir yapılandırma azaltması yok.
Bu ayar yama öncesinde geçici çözüm olarak dolaştı ve yayın bunu asla tam bir düzeltme olmadığını doğruladı. Oturum yükleme ilerlemesi varsayılan olarak açık ve bir istek kurulmadan önce oturum işleme ulaşabiliyor; bu da CVE-2026-109619 için onaylanmış bir saldırı yolunda rol oynamasının ve CVE-2026-109618 için kapatmanın bir şey yapmamasının nedeni.
"Söyleyebileceğim tek şey tek azaltmanın PHP’yi yama yapmak/güncellemek olduğudur. Maalesef çok fazla şey biliyorum," PHP çekirdek geliştiricisi Gina Peter Banyard, ayarın yeterli olabileceği önerisine yanıt olarak yayın öncesinde yazdı.
Güncelledikten sonra bellek ayarlarınızı gözden geçirin. Düzeltme yeni bir sert bellek sınırı ekliyor ve bu sınıra ulaşmak süreci sonlandırıyor ve kapanış işleyicilerinin çalışmasını durduruyor, bu yüzden memory_limit ve post_max_size değerlerini uygulamanızın ihtiyacı ile karşılaştırın.
Zaten yamadıysanız ancak daha önceki bir ihlali şüpheli görüyorsanız, araştırmacılar olağandışı çok parçalı isteklerin ardından bellek sınırı hataları veya tekrarlayan HTTP 500 yanıtları, tuhaf derecede büyük PHPSESSID yanıt çerezleri ve PHP çalışanlarının açıklanamayan yeniden başlatmaları izlenmesini öneriyor.
Saldırı görülüyor mu
Yama yayınlanmadan önce Cloudflare açıkların istismar edilmeye çalışıldığını gördüğünü söyledi. Cloudflare CTO’su Dane Knecht, "Erken saldırılar ortaya çıkmaya başladı ve yeni vektörler çıktıkça azaltmaları güncelliyoruz" dedi ve Cloudflare’in dağıttığı güvenlik duvarı kurallarının geçici olduğunu belirterek yöneticileri yama yapmaya çağırdı.
Başarılı bir ihlal teyit eden bir kaynak yok. CVE-2026-109618’i yeniden üreten watchTowr, 21 Ekim 11:26 UTC itibarıyla vahşi doğada istismar bildirmiyor ve her iki açık da o sırada CISA’nın Bilinen İstismar Edilen Kırılganlıklar kataloğunda değildi.
Bazı kuruluşlar bir ihlale yanıt olarak değil önlem olarak hizmetleri çevrimdışı aldı. BambooHR, hizmetini Amerika Birleşik Devletleri, Kanada ve İrlanda’da çevrimdışı aldı, ücretlendirmenin kesileceği konusunda uyardı ve henüz bir geri yükleme zamanı olmadığını söyledi.
Hollanda’da NOS’un bildirdiğine göre MijnOverheid, DigiD, parlamento alt kanadının sitesi, ulusal siber güvenlik merkezi ve çeşitli eğitim sistemleri çevrimdışı oldu; merkez açığın kötüye kullanıldığını görmediğini ancak herkesin yama yapmasını istediğini söyledi.
Nasıl ortaya çıktı
Bir sızıntı yayını öne çekti. 20 Ekim’de The Hacker News’in bildirdiğine göre Hacker News’te iki PHP uzaktan kod çalıştırma açığının, iki CVE tanımlayıcısı ile 22 Ekim’de açıklanacağı yönünde güvenilir bir ipucuyla bir gönderi paylaşıldı.
PHP o akşam önceden bir duyuru yayınladı ve yayını 21 Ekim’e taşıdı. Sızıntının iddia ettiği CVSS 10,0 puanı PHP’ninki değildi; PHP her iki açığı da 9,2 olarak derecelendiriyor.
Açıklar Wiz Research, Calif ve OpenAI’nin Codex Security ekibi tarafından bulundu; düzeltme PHP güvenlik ekibi ve Google’ın Gemini ekibiyle birlikte çalışılarak yapıldı. Altta yatan kod PHP’de bir on yıldan uzun süredir bulunuyordu.
Araştırmacılar, AI modellerinin bu uzun süredir var olan açıkları çalışan istismarlara dönüştürmeye yardımcı olduğunu söylüyor; bu, bir araştırmacının yaklaşık bir haftada yapabildiği şeyi, aksi halde bir ekibin aylar alacağını belirtiyor.
2004’ten PHP araştırmasına kadar uzanan hatayı izleyen Calif, hedefin geçmişini bilmenin hâlâ önemli olduğunu ve mevcut modellerin kendi başlarına belirsiz, yirmi yıllık ilkelere güvenilir şekilde başlamadığını söylüyor.
