PHP2Shell Açığı İçin Kritik Güncelleme

PHP projesi, sunucu tarafında çalışan uygulamaları etkileyen iki kritik güvenlik açığını gidermek için 21 Ekim 2026'da olağan dışı bir güvenlik güncellemesi yayımladı. CVE-2026-109618 ve CVE-2026-109619 olarak izlenen açıklar, birlikte “PHP2Shell” adıyla anılıyor. Her iki zafiyet de CVSS v4.0 ölçeğinde 9.2 puanla kritik olarak sınıflandırıldı ve kimlik doğrulaması olmayan bir saldırganın PHP süreci üzerinden uzaktan kod çalıştırmasına neden olabiliyor.

Açıklar belirli bir içerik yönetim sistemi ya da eklentiyle sınırlı değil; PHP yorumlayıcısının istek başlatma, hata işleme ve bellek temizleme süreçlerinden kaynaklanıyor. Bu nedenle PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed üzerinden web isteği kabul eden kurulumlar risk altında. WordPress, Drupal, Joomla, Magento, WooCommerce, Laravel ve benzeri uygulamalar kendi kodlarında sorun bulunmasa bile temel PHP çalışma zamanı savunmasızsa etkilenebiliyor.

PHP2Shell nasıl ortaya çıktı?

Güvenlik açığına ilişkin ilk bilgiler 20 Ekim'de, iki kritik uzaktan kod çalıştırma açığının ertesi gün açıklanacağını öne süren anonim bir çevrim içi paylaşımın yayılmasıyla kamuya taşındı. Paylaşım kısa süre içinde kaldırılmış olsa da ekran görüntüleri, ayrılmış CVE numaraları ve “PHP 5'ten bu yana tüm sürümlerin etkilendiği” iddiası sosyal medyada dolaşıma girdi. PHP güvenlik ekibi bunun üzerine 21 Ekim saat 14.00 UTC için planlanan olağan dışı güvenlik sürümünü duyurdu ve teknik ayrıntıların daha erken sızması ya da saldırıların başlaması hâlinde takvimi öne çekebileceğini bildirdi.

Koordineli açıklama öncesinde teknik ayrıntıların sızması, saldırı hazırlığına ilişkin kaygıları artırdı. watchTowr, CVE-2026-109618'i yeniden ürettiğini ve iki açığın da uzaktan kod çalıştırma amacıyla kullanılabileceğini değerlendirdi. Cloudflare ise 21 Ekim günü 07.43 UTC itibarıyla erken saldırı girişimleri gördüğünü açıkladı. Patchstack de aynı gün 07.34 UTC'de barındırma ortaklarından aktif istismar olayları bildirimleri aldığını aktardı. Bununla birlikte Recorded Future, mevcut raporların başarılı ihlallerin toplam boyutunu veya doğrulanmış ele geçirmelerin sayısını ortaya koymaya yetmediğini belirtti.

Açıkların keşif sürecinde Calif, Wiz Research ve OpenAI'ın rol aldığı bildirildi. Google Cloud'un açıklamasına göre Wiz, farklı modellerden yararlanarak açığın bulunması, istismar geliştirme, saldırı tespiti ve yamanın doğrulanmasına katkı sağladı; açıklamada Gemini 4 Argon'un da bu süreçte önemli katkı sunduğu ifade edildi. PHP güvenlik ekibi, koordineli açıklama kapsamında düzeltmeleri hazırladı. Teknik bulguların ve kamuya açık kavram kanıtlarının ortaya çıkmasından sonra saldırganların savunmasız sistemleri taraması için gereken bilgiler de erişilebilir hâle geldi.

Açıkların teknik etkisi

CVE-2026-109618, bellek yetersizliği durumunda PHP'nin mevcut isteği sonlandırma biçimiyle ilişkili. Bellek tahsisi başarısız olduğunda istek verilerinin yalnızca bir bölümü başlatılmış durumda kalabiliyor; temizlik işlemi ise geçersiz veya kısmen hazırlanmış veriyi geçerli kabul edebiliyor. Sansec bu durumu use-after-free sınıfında bir hata olarak tanımlıyor. Bazı saldırı yollarında PHP'nin oturum yükleme ilerlemesi işleyicisi devreye giriyor ve serbest bırakılmış çalışma belleği istemciye PHPSESSID yanıt çerezi içinde dönebiliyor. Bu bellekte parolalar, oturum belirteçleri, API anahtarları veya TLS özel anahtarları bulunabilir.

CVE-2026-109619 ise bir isteğe ait iç durumun, onu taşıyan bellek serbest bırakıldıktan sonra yaşamaya devam etmesiyle ilgili. Aynı çalışan süreçte ele alınan sonraki istek, normal başlatma işlemi durumu sıfırlamadan önce bu eski işaretçiyi kullanabiliyor. Wiz Research; hata geri izlemeleriyle ilişkili use-after-free yolunun yanı sıra OPcache tür karmaşası içeren bir başka yol belirledi. Her iki açık da bellek ifşası, bellek bozulması ve uzaktan kod çalıştırma için kullanılabilecek koşullar oluşturabiliyor. Sansec'e göre açıkların etkisi uygulama kodundan önce ortaya çıktığı için oturum başlatmayan uygulamalar dahi belirli bellek sızıntısı yollarından korunmuyor.

Wiz Research, varsayılan kurulumlarla çalışan güncel WordPress, Drupal ve Joomla konteynerlerinde kimlik doğrulamasız uzaktan kod çalıştırmayı gösterdiğini açıkladı. Sansec'in aktardığı testlerde Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 ve WHMCS üzerinde de saldırı yolları gösterildi. Saldırı aracı PHP2Shell'in iki açığı tek bir saldırıda birleştirdiği ve giriş yapılmasını gerektirmediği bildirildi.

Hangi sürümler yamalandı?

PHP projesinin yayımladığı düzeltmeler PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 sürümlerinde bulunuyor. RunZero ve Recorded Future, bu sürümlerin altındaki PHP 8.2, 8.3, 8.4 ve 8.5 sürümlerinin etkilenen aralıkta olduğunu belirtiyor. PHP 8.1 ve daha eski sürümler artık PHP projesinden düzenli güvenlik güncellemesi almıyor. Bazı Linux dağıtımları ve uzun süreli destek sağlayıcıları düzeltmeleri bu eski dallara geri taşıyabilir; kaynak koddan derleme yapanlar için PHP güvenlik ekibinin PHP 7.4, 8.0 ve 8.1'e yönelik asgari geri taşımaları da paylaştığı bildirildi. Bu nedenle eski sürümlerdeki yöneticilerin dağıtım veya barındırma sağlayıcısının paketlerini kontrol etmesi ya da desteklenen bir dala geçmesi gerekiyor.

Recorded Future'ın aktardığı iki bağımsız internet taraması, dışarıdan görülebilen PHP kurulumlarının önemli bölümünün kullanım ömrü sona ermiş dallarda çalıştığını gösteriyor. Modat, sürüm bilgisi okunabilen hizmetler arasında yaklaşık yüzde 79'unun artık desteklenmeyen bir PHP dalında olduğunu hesapladı; PHP 7.4 tek başına 878.761 hizmetle en geniş gruplardan birini oluşturdu. VirusTotal ise PHP çalıştırdığı değerlendirilen yaklaşık 5,1 milyon IP adresi belirledi; sürümünü açıklayan sistemlerde 5.4 ile 8.1 arasındaki kullanım ömrü sona ermiş dallar, desteklenen dallardan daha kalabalıktı. Bu taramalar kesin olarak savunmasız sunucu sayısını göstermiyor, ancak yamalanmamış eski kurulumların kapsamını ortaya koyuyor.

Google Cloud, PHP kullanan müşterilerinin uygulamalarını derhâl PHP 8.2 veya daha yeni, yamalı bir sürüme taşımasını ve hizmetleri yeniden dağıtmasını istedi. App Engine Standard ortamında PHP 8.2 ve üzeri için taban imaj güncellemeleri otomatik uygulanabiliyor. App Engine Flexible, özel çalışma zamanları, otomatik taban imaj güncellemeleri etkin olmayan Cloud Run hizmetleri ve kendi konteyner imajını kullanan GKE kurulumları için yeniden derleme veya yeniden dağıtım gerekiyor. Marketplace üzerinden kullanılan içerik yönetim sistemleri ve LAMP yığınlarında da çözüm sağlayıcının güncellemesi uygulanmalı. Desteklenmeyen çalışma zamanları otomatik olarak yamalanmayacağı için PHP 8.1 ve daha eski sürümler ayrıca ele alınmalı.

Güncelleme tamamlanana kadar bazı geçici önlemler saldırı yüzeyini azaltabilir, ancak bunlar tam çözüm sayılmıyor. Patchstack ve RunZero, CVE-2026-109618 için uygulamanın değiştiremeyeceği biçimde memory_limit değerinin -1 yapılmasını, post_max_size ve yükleme boyutlarının düşürülmesini, istek ve multipart parça sınırlarının web sunucusu veya vekil üzerinde uygulanmasını öneriyor. CVE-2026-109619 için session.upload_progress.enabled değerinin kapatılması ve tüm çalışanların yeniden başlatılması; PHP 8.5'te ayrıca fatal_error_backtraces değerinin devre dışı bırakılması öneriliyor. Sansec, bilinen tetikleyicilerin multipart/form-data istekleri olduğunu belirterek web sunucusunda bu isteklerin geçici olarak reddedilmesini, ancak bunun dosya yüklemelerini ve bazı ödeme akışlarını bozabileceğini bildiriyor.

Yama hemen uygulanamıyorsa yüksek riskli sistemin çevrim dışına alınması veya yalnızca GET ve HEAD isteklerine izin verilmesi de gündeme gelebilir. Sansec, bakım modlarının tek başına yeterli olmayabileceğini; çünkü PHP'nin isteği uygulama kodu çalışmadan önce işlediğini belirtiyor. Cloud Armor, bilinen saldırı yollarına karşı yönetilen kurallar ve büyük istek gövdelerinin incelenmesini sınırlayan politikalar sunuyor. Cloudflare da bilinen istismar vektörleri için WAF kuralları yayımladı, ancak bu önlemler yalnızca trafiğin gerçekten ilgili ağ geçidinden geçtiği durumlarda yardımcı oluyor ve PHP güncellemesinin yerini tutmuyor.

Yöneticilerin olağandışı multipart isteklerini, bellek sınırı hatalarını, tekrarlanan HTTP 500 yanıtlarını, beklenmeyen PHP çalışanı yeniden başlatmalarını ve anormal büyüklükte PHPSESSID çerezlerini izlemesi öneriliyor. PHP-FPM, php-cgi veya apache2/httpd süreçlerinin kabuk, yorumlayıcı ya da curl, wget ve nc gibi indirme araçlarını başlatması da inceleme gerektiren bir işaret olabilir. Bu göstergeler tek başına ihlal kanıtı değil; ancak şüpheli bir durumda sunucunun izole edilmesi, web sunucusu ve PHP günlüklerinin korunması, web kök dizinindeki yeni dosyaların ve webshell'lerin incelenmesi, ayrıca sistemde bulunan kimlik bilgilerinin döndürülmesi gerekiyor. PHP'nin güvenlik duyurusundaki düzeltmeler uygulanmadıkça sistemler savunmasız kabul edilmeli.