PHP2Shell, doğrudan PHP motorunda bulunan iki kritik zafiyetin (CVE-2026-109618 ve CVE-2026-109619) ortak adı. PHP projesi 21 Ekim 2026'da acil yamaları yayınladı ve o günden beri ciddi kaynakların hepsi aynı noktanın altını çiziyor: PHP2Shell açığı runtime'da. WordPress'i, Laravel'i ya da kendi kodunuzu güncellemek bu açığı kapatmıyor. Web isteklerine PHP ile yanıt veren bir sisteminiz varsa, risk altında olup olmadığınızı alttaki PHP sürümü belirliyor.

Bu yazıda ne olduğunu, kaynakların nerede ayrıştığını ve bu hafta atılması gereken somut adımları anlatıyoruz.

PHP2Shell'de ne oldu?

PHP ekibi 21 Ekim'de 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerini yayınladı. Sürüm notu bunu, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya (RCE) imkân verebilen iki kritik açığı kapatan bir güvenlik sürümü olarak tanımlıyor. Qualys'in ifadesiyle tek tam çözüm güncellemek.

PHP iki açığı da CVSS v4.0'a göre 9.2 (Kritik) olarak puanlıyor.

PHP Foundation'ın açıklamasına göre:

  • Apache + mod_php: Giriş yapılmamış bir istek, açığı herhangi bir uygulama kodu çalışmadan önce tetikleyebiliyor. Varsayılan ayarlarla tam RCE gösterilmiş.
  • PHP-FPM: RCE, uygulama seviyesindeki kod yolları üzerinden doğrulanmış.
  • İkinci CVE bir bellek ömrü hatası. İç durum, önceki bir isteğe ait belleği göstermeye devam edebiliyor; aynı worker'ın işlediği sonraki bir istek de serbest bırakılmış bu belleği kullanabiliyor.

Qualys'e göre araştırmacılar, PHP worker belleğinin giriş yapılmadan sızdırılabildiğini de gösterdi. Bu bellekte parolalar, oturum token'ları ve API anahtarları bulunabiliyor. Bu ayrıntı yalnızca yama için değil, sonrasındaki temizlik için de önemli.

İfşa süreci de sorunsuz geçmedi. PHP Foundation, PHP'yi Patch the Planet programına dahil ettiğini ve bu kapsamda güvenlik firması Calif'in 30 Temmuz'da PHP'yi denetlemeye başladığını söylüyor. Sansec'in zaman çizelgesine göre Calif ilk açığı 11 Ağustos'ta, Wiz Research ise açıkları 24 Ağustos'ta bildirdi; Foundation, OpenAI'ın 18 Eylül'de ek saldırı yolları raporladığını da ekliyor. Teknik detaylar 20 Ekim'de, düzeltilmiş sürümler 21 Ekim'de çıkmadan önce sızdı. Foundation, yaşanan gecikmeyi açıkça yapısal bir başarısızlık olarak nitelendirdi.

PHP2Shell açığı neden uygulama değil, runtime sorunu?

Toplantılarda en kolay gözden kaçan kısım bu. "WordPress'in son sürümündeyiz" ya da "Laravel'i geçen ay güncelledik" demek bir cevap değil.

SECURITY.COM'un analizine göre web isteği karşılayan her PHP kurulumu etkileniyor: PHP-FPM, Apache + mod_php, php-cgi, FrankenPHP ve LiteSpeed. Etkilenen sürümler PHP 5.4.0'a kadar geri gidiyor. Yamalanmış bir uygulama, yamalanmamış bir runtime üzerinde çalışıyorsa savunmasız kalıyor. Sansec, Calif'in Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony ve WHMCS'in güncel sürümlerinde giriş gerektirmeyen kod çalıştırma raporladığını aktarıyor.

Açık, kimsenin "PHP sunucusu" olarak görmediği sistemlere de uzanıyor. SECURITY.COM, PHP'yi içinde barındıran üçüncü taraf ürünlerin, appliance'ların, container'ların ve hosting platformlarının da etkilenebileceğini belirtiyor; Hollanda'nın NCSC'si etkilenen üçüncü taraf ürünlerin bir listesini tutuyor. Ağ cihazları, hosting panelleri ve üçüncü taraf appliance'lar içlerinde PHP barındırabiliyor.

Gerçekten istismar ediliyor mu? Kaynaklar ayrışıyor

Manşetleri dikkatli okumakta fayda var, çünkü veriler birbiriyle tam örtüşmüyor:

Kaynak Ne diyor
Amazon Threat Intelligence MadPot verilerinde, kamuya açıklanmadan dört gün önce, 17 Ekim tarihli bir istismar denemesi tespit etti; şimdi geniş çaplı istismar denemeleri raporluyor
CISA Uyarıyı yayınladığı anda başarılı bir istismar gözlemlememişti
Sansec (22 Ekim güncellemesi) Toplu istismar ilk gün beklenenden daha az olası; saldırı hedef sunucu hakkında özel bilgi ve belirli koşullar gerektiriyor, açık exploit'ler varsayılan PHP kurulumunda çalışmıyor

Deneme, başarılı bir ihlal demek değil ve başarılı bir saldırıyı doğrulayan bir kaynak görmedik. Ancak resmi kurumlar bunu beklemiyor. CISA acil yama çağrısı yapıyor ve hemen güncelleme yapamayan ya da hâlâ PHP 8.1 veya daha eskisini kullanan kurumların PHP tabanlı sistemleri yamalanana kadar çevrimdışı almasını öneriyor. İngiltere'nin NCSC'si ve diğer ulusal kurumlar da kendi uyarılarını yayımladı.

Bizim yorumumuz: Sansec'in tespiti önceliklendirme için faydalı, ama beklemek için gerekçe değil. Kamuya açık PoC kodu raporlandı ve AWS'nin verileri, açık duyurulmadan önce birilerinin yoklama yaptığını gösteriyor.

Bu hafta yapılması gerekenler

1. Uygulamaları değil, runtime'ları envanterleyin

Uygulama listeniz yanlış başlangıç noktası. PHP binary'sinin çalıştığı her yeri bulun:

  • Production ve staging sunucuları, unutulmuş mikro siteler ve eski kampanya sayfaları dahil
  • Docker base image'ları (FROM php:...) ve bunlardan türetilen her image
  • Hosting paneli sunucuları ve paylaşımlı hosting hesapları
  • İçinde PHP gömülü gelen cihazlar ve eski ERP/CRM modülleri
  • CI'ın ayağa kaldırdığı önizleme ve demo ortamları

Hızlı bir kontrol:

# Sunucudaki PHP sürümü (CLI)
php -r 'echo PHP_VERSION, PHP_EOL;'

# FPM binary'si (dağıtıma göre adı değişir, ör. php-fpm8.3)
php-fpm -v

# Container image içindeki PHP sürümü
docker run --rm --entrypoint php your-image:tag -r 'echo PHP_VERSION, PHP_EOL;'

# Yamalı minimum sürümler: 8.5.12, 8.4.27, 8.3.36, 8.2.35

Aynı makinede CLI ile web tarafındaki SAPI farklı build'ler olabilir; web sunucusunun gerçekte yüklediği sürümü mutlaka doğrulayın.

2. Yamalayın, sonra PHP yükleyen her şeyi yeniden başlatın

Paketi kurmak işin yarısı. Çalışan süreçler, yeniden başlatılana kadar savunmasız kodu bellekte tutmaya devam ediyor. PHP-FPM pool'larını, Apache'yi (mod_php için), LiteSpeed'i ve FrankenPHP'yi yeniden başlatın. Container'larda yamalı base image ile yeniden build alıp deploy edin; yeni tag çekmek, hâlihazırda çalışan bir container'ı değiştirmez.

3. Desteği bitmiş (EOL) runtime'ları iş riski olarak görün

PHP 8.1 ve öncesi için resmi bir sürüm çıkmadı. Proje 7.4, 8.0 ve 8.1 için sınırlı kaynak kod backport'ları yayınladı; işletim sistemi sağlayıcınız backport'lu paketler sunuyor olabilir, mutlaka kontrol edin. Sansec'e göre resmi Docker php image'ı 8.1 ve öncesi için düzeltme almıyor. PHP 7.x'e bağımlı eski bir modülünüz varsa, taşıma maliyetiyle onu açık tutmanın riskini bu hafta rakamlarla karşılaştırın.

4. WAF kurallarını köprü olarak kullanın

Cloudflare, düzeltilmiş sürümler çıkmadan önce, 21 Ekim 07:43 UTC'de ilk saldırıları bildirdi; Qualys bu saldırıların bir kısmının Cloudflare'in korumalarını aşmaya çalıştığını not ediyor. Microsoft da WAF önlemlerinin yamayı tamamladığını, yerine geçmediğini açıkça belirtiyor. Bunlar size zaman kazandırır, ticket'ı kapatmaz.

5. Geç kaldıysanız sızıntı olmuş gibi davranın (Loop'un önerisi)

Bu, PHP, CISA ya da Microsoft'un değil, bizim görüşümüz: İnternete açık bir PHP sunucusu yamasız kaldıysa, access ve error log'larını 17 Ekim'e kadar geriye doğru inceleyin; sunucunun eriştiği veritabanı parolalarını, API anahtarlarını ve session secret'larını değiştirmeyi değerlendirin. Bellek sızdırma açığı, sistem tamamen ele geçirilmese bile kimlik bilgisi sızıntısını gerçekçi bir ihtimal hâline getiriyor.

PHP'yi Azure'da çalıştırıyorsanız

Müşteri projelerimizin önemli bir kısmı Azure App Service üzerinde. Microsoft'un paylaştığı ayrıntılar şöyle:

  • App Service on Linux: Yamalı yerleşik PHP image'ları hem Latest hem Standard Platform Release Channel'a dağıtıldı. EOL PHP sürümleri yama almıyor ve release channel değiştirmek EOL bir runtime'ı desteklenen bir sürüme yükseltmiyor.
  • App Service on Windows: Yerleşik PHP runtime'ları EOL durumda ve şu an planlanmış bir yama yok. Microsoft mümkünse Linux'a geçilmesini öneriyor. Çoğu uygulama için bu bir deployment değişikliği, ama extension'ları, dosya yollarını ve IIS'e özgü ayarları test edin.
  • Custom container'lar: Yamalı base image ile yeniden build alıp deploy edin; EOL sürümleri hedefleyen uygulamaları yükseltin.
  • Azure WAF: Azure Front Door WAF için yönetilen bir kural dağıtılıyordu ve 28 Ekim'de tamamlanması bekleniyordu. Microsoft'un yayınladığı custom kurallar belirli saldırı yüzeylerini daraltıyor, ancak iki açığa karşı da tam koruma sağlamıyor.

Linux'taki bir web app'in hangi PHP sürümünü hedeflediğini görmek için:

az webapp config show \
  --name <app-name> \
  --resource-group <resource-group> \
  --query linuxFxVersion

Sonuç EOL bir sürümü gösteriyorsa platform yaması size ulaşmayacak. Yükseltmeyi şimdiden planlayın.

Öne çıkanlar

  • PHP2Shell, PHP runtime'ındaki bir açık; yamasız runtime üzerindeki güncel CMS ya da framework de savunmasız.
  • 8.5.12, 8.4.27, 8.3.36 veya 8.2.35'e yükseltin, ardından tüm PHP süreçlerini yeniden başlatıp container'ları yeniden deploy edin.
  • Runtime envanterini her yerde çıkarın: image'lar, staging, mikro siteler, hosting panelleri ve cihazlar.
  • PHP 8.1 ve öncesi için resmi sürüm yok; bunları iş riski olarak ele alın ve işletim sistemi backport'larını kontrol edin.
  • Azure'da Windows üzerindeki yerleşik PHP'den çıkın, Linux uygulamalarının EOL sürümde olmadığını doğrulayın, WAF'ı yalnızca köprü olarak görün.
  • İstismar verileri karışık, ama resmi kurumlar hemen yama diyor. Geç kaldıysanız log'ları 17 Ekim'e kadar incelemenizi ve secret'ları yenilemenizi öneriyoruz.