PHP, kimliksiz kod çalıştırmaya izin veren iki kritik açık için acil sürüm yayımladı

PHP ekibi iki kritik açık için acil sürüm çıkardı

PHP projesinin 21 Ekim 2026 tarihli güvenlik danışma bülteni, PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinin kimliği doğrulanmamış uzaktan kod çalıştırmaya izin verebilen iki kritik açığı düzelttiğini bildiriyor. Bülten, web isteklerine hizmet veren tüm PHP kurulumlarını riskli sayıyor ve bütün kullanıcıları hemen güncellemeye çağırıyor. Açıklar PHP2Shell adıyla anılıyor; bu adı PHP'nin duyurusu kullanmıyor, Cloudflare ve basın kullanıyor. BleepingComputer'a göre adı araştırmacılar kullanmaya başladı.

Süreç bir gün önce başlamıştı: PHP 20 Ekim'de ön duyuru yaparak sürümü 21 Ekim 14:00 UTC'ye planladı, ayrıntılar kamuya çıkarsa ya da sahada istismar görülürse daha erken yayımlama hakkını saklı tuttu. BleepingComputer, açıkları Calif, Wiz ve OpenAI güvenlik araştırmacılarının bulduğunu yazıyor. OpenAI'ın kendi açıklamasına göre Calif kritik bir açığı GPT-5.6 Sol ile belirledi, Wiz de iki açığı bağımsız olarak buldu ve bildirdi. Linux dağıtımları ile LTS satıcıları yamaları önceden aldı.

İki açık, bellek hatası ve eski durum üzerinden kod çalıştırmaya götürüyor

CVE-2026-109618, bültende bellek yetersizliği kaynaklı bozulma üzerinden uzaktan kod çalıştırma olarak adlandırılıyor: bellek tükenmesi PHP'yi iç istek verisi yalnızca kısmen başlatılmışken kesebiliyor ve istek temizliği geçersiz veriyi geçerli sayabiliyor. CVE-2026-109619 ise eski global durum üzerinden işliyor: isteğe ait iç durum, dayandığı bellek serbest bırakıldıktan sonra da kalabiliyor ve aynı işçi tarafından işlenen sonraki istek bunu kullanabiliyor. Danışma bülteni PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed'i riskli çalışma biçimleri olarak listeliyor; en yüksek risk mod_php'de. PHP, mod_php için gösterilmiş bir istismar bulunduğunu, kimliksiz bir isteğin uygulama kodu çalışmadan önce saldırıyı tetikleyebildiğini söylüyor.

Eski sürümlerde tablo farklı. PHP 8.1 ve eskisi proje güncellemesi almıyor; güvenlik ekibi kaynaktan derleyenler için 7.4, 8.0 ve 8.1'e minimal yedek yamalar sağladı, bazı dağıtımlar ve LTS satıcıları da yedek düzeltme sunuyor, bu yüzden satıcıya başvurulması öneriliyor. PHP 8.2.35 sürüm notu da 8.2 serisinin ömür sonunu 31 Aralık 2026 olarak veriyor. Geçici önlemler arasında memory_limit=-1, düşük bir post_max_size sınırı ve session.upload_progress.enabled=0 var; ancak bülten bunların maruziyeti azalttığını, kurulumu güvenli yapmadığını ve tam çözümün yalnızca güncelleme olduğunu söylüyor. RLIMIT_AS ya da RLIMIT_DATA kullanılmamasını da istiyor, çünkü bunlar savunmasız bellek ayırma hatasını tetikleyebilir.

Sahadaki durum kaynaklara göre farklı, ölçek ise büyük

Saldırı konusunda kaynaklar aynı şeyi söylemiyor, bu yüzden her biri kendi adına aktarılıyor. PHP, mod_php için gösterilmiş bir istismar olduğunu belirtiyor. Cloudflare kendi blogunda açıkların resmi tarihten önce sızdığını ve müşterilerini hedefleyen saldırı trafiği gözlediğini yazıyor. BleepingComputer'a göre Cloudflare CTO'su Dane Knecht, yamalardan önce her iki açığı hedefleyen erken saldırılar gördüklerini doğruladı ve Cloudflare'ın WAF kurallarını geçici olarak niteledi. TechCrunch ise OpenAI'a göre açıkların saldırganlardan önce araştırmacılarca bulunduğunu, bu yüzden sahada istismar raporu olmadığını yazıyor. Cloudflare varsayılan korumasını 21 Ekim 03:02 UTC'de, kamuya açıklamadan yaklaşık dokuz saat önce devreye aldı ve Ücretsiz Yönetilen Kural Seti'ne yedi yeni kural ekledi. Şirket, WAF'ın ek bir katman olduğunu, kod ya da eklenti güncellemesinin açıkları kapatmadığını ve PHP güncellemesinin yönetici ya da barındırma sağlayıcısınca yapılması gerektiğini yazıyor.

Ölçek için BleepingComputer, VirusTotal tahminlerine dayanarak internete açık 5,1 milyondan fazla PHP sunucusu olduğunu, yaklaşık 3,8 milyonunda en az bir port açık bulunduğunu aktarıyor ve PHP'nin web sitelerinin yaklaşık yüzde 75-80'ine güç verdiğini ekliyor; TechCrunch yaklaşık yüzde 70 diyor. Birleşik Krallık NCSC, BleepingComputer'a göre kuruluşlara hemen güncelleme yapmalarını ya da yama gelene kadar sistemleri çevrim dışı almalarını önerdi. Search Engine Roundtable, Reuters'a atıfla Avrupa'da bazı devlet, okul ve hastane sitelerinin Çarşamba günü çevrim dışı alındığını aktarıyor. Aynı yazıya göre Google'dan John Mueller, plansız güncelleme için siteyi kapatanların zaman aşımı, 404 ya da 500 yerine HTTP 503 döndürmesini önerdi ve bunun PHP dışında, DNS ya da CDN üzerinden de yapılabileceğini söyledi.

Kaynaklarda Türkiye yok, bu bölüm yorum

Bu yazı için açtığımız sekiz kaynak sayfasının hiçbirinde Türkiye geçmiyor. Türkiye'deki barındırma sağlayıcılarının hangi PHP sürümünü çalıştırdığı, ne zaman yama uyguladığı, yerel kurumların etkilenip etkilenmediği ve Türkiye'den bir kurumun uyarı yapıp yapmadığı gibi sorulara bu kaynaklardan cevap çıkmıyor. Bu yüzden bu bölüm olgu değil, açıkça UNALSOFT yorumudur.

Yorumumuz şu: küçük ve orta ölçekli işletme siteleri çoğunlukla WordPress gibi PHP tabanlı sistemlerde çalışır ve PHP sürümünü genellikle barındırma sağlayıcısı yönetir. TechCrunch'a göre WordPress da açığın WordPress'e özgü olmadığını, bu CMS'yi kullanan sitelerin sunucularını yamalaması ve barındırıcılarıyla çalışması gerektiğini belirtiyor. Yani eklenti güncellemesi bu açığı kapatmaz; asıl soru sağlayıcının yamayı ne zaman uygulayacağı. PHP sürüm zorunluluğunun mağazalar için ne anlama geldiğini 29 Eylül'de ayrıca yazmıştık; o yazı bu açıklardan bağımsız.

Kaynaklar

PHP.net, güvenlik danışma bülteni (ana sayfa) · PHP.net, 2026 haber arşivi · Cloudflare Blog, PHP açıklarına karşı WAF koruması · BleepingComputer, PHP kritik PHP2Shell açıkları için acil yamalar yayımladı · BleepingComputer, PHP yöneticileri iki kritik açık için uyardı · Search Engine Roundtable, Google ve PHP2Shell · OpenAI, kritik açıkların koordineli duyurusu · TechCrunch, PHP açıkları interneti panikletiyor