KRİTİK GÜVENLİK DUYURUSU

PHP2Shell: PHP'de kritik uzaktan kod çalıştırma açığı

21 Ekim 2026 • CVE-2026-109618 • CVE-2026-109619 • CVSS 9.2 (Kritik)

Özet: PHP ekibi bugün (21 Ekim 2026) iki kritik güvenlik açığı için acil güncelleme yayınladı. Açıklar, kimlik doğrulama gerektirmeden uzaktan kod çalıştırmaya (RCE) izin veriyor ve istismar denemeleri şimdiden gözlemleniyor. PHP ile çalışan tüm internete açık sistemlerin beklemeden güncellenmesi gerekiyor.

Açıklar neler?

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — Bellek yetersizliği (OOM) durumunda PHP, isteği yarıda keserken iç veriler yarı-ilklenmiş halde kalabiliyor. Temizlik aşaması bu geçersiz veriyi geçerli sanıp hiç ayrılmamış belleği serbest bırakmaya çalışıyor; saldırganın kontrol ettiği eski bellek içeriğiyle birleşince bellek bozulması ve kod çalıştırma mümkün oluyor.

CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — Bir isteğe ait iç durum (hata, oturum, genişletme durumu), belleği serbest bırakıldıktan sonra çalışan (worker) üzerinde kalabiliyor. Aynı worker'ın işlediği sonraki istek, normal başlatma yapılmadan önce bu bayat durumu kullanırsa use-after-free oluşuyor ve uzaktan kod çalıştırmaya kadar gidebiliyor.

İki açık da aynı kök sorundan besleniyor: isteğin anormal bitmesi PHP'nin belleğini bozuk durumda bırakabiliyor. PHP ekibi riski en yüksek mod_php kurulumlarında görüyor; uygulama kodu hiç çalışmadan, tek bir kimlik doğrulamasız istekle tetiklenebilen bir istismar gösterildi.

Kimler etkileniyor?

Web isteği sunan her PHP kurulumu: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed.
WordPress, Joomla, Drupal gibi PHP tabanlı CMS çalıştıran tüm siteler.
Kendi PHP çalıştırmasanız bile, içinde PHP gömülü gelen üçüncü parti ürünler (panel, appliance, hazır paketler).
Etkilenen aralık: PHP 5.4'ten 8.5.11'e kadar tüm sürümler.

Güvenli sürümler

Dal	Açıklı (öncesi)	Güncel güvenli sürüm
PHP 8.5	< 8.5.12	8.5.12
PHP 8.4	< 8.4.27	8.4.27
PHP 8.3	< 8.3.36	8.3.36
PHP 8.2	< 8.2.35	8.2.35
PHP 8.1 ve altı	Tümü (ömrü dolmuş)	PHP projesinden düzeltme yok — dağıtım/LTS backport'u ya da desteklenen sürüme geçiş şart

Kaynak derleme yapanlar için PHP ekibi 7.4, 8.0 ve 8.1'e minimal kaynak backport'ları da yayınladı. Dağıtım paketi kullanıyorsanız dağıtımınızın güncellemesini bekleyin; Remi deposu kullanıcılarının yayın günü güncelleme alamayacağı, dağıtım paketine geçmelerinin önerildiği duyuruldu.

Hemen yapılacaklar — kontrol listesi

☐ Envanter çıkarın: internete açık sistemlerden başlayarak tüm PHP kurulumlarını (gömülü PHP içeren ürünler dahil) listeleyin.
☐ Yukarıdaki güvenli sürümlerden birine bugün güncelleyin; güncelleyemiyorsanız sistemi izole edin veya geçici olarak yayından kaldırın.
☐ PHP 8.1 ve altı kullanıyorsanız desteklenen sürüme geçiş planını hemen başlatın.
☐ Güncelleme öncesi sızıntı şüphesini değerlendirin: bilinmeyen dosyalar, yeni kullanıcılar, şüpheli zamanlanmış görevler ve web kabuğu (webshell) izleri arayın.
☐ CMS ve eklentileri de güncelleyin; WAF kurallarını geçici önlem olarak görün — PHP ekibine göre kalıcı tek çözüm yamanın kendisidir, bilinen bir "hafifletme" (mitigation) yoktur.
☐ Güncelleme sonrası sürümü doğrulayın: php -v ve web tarafında çalışan worker'ların da yeni sürümle yeniden başladığını kontrol edin.

⚠️ Önemli notlar

İstismar denemeleri çoktan başladı: Teknik detaylar ve kavram kanıtı (PoC) kodlar halka açılmaya başladı; Cloudflare, yama yayınlanmadan önce bile saldırı girişimleri gözlemlediğini duyurdu. "Bize bir şey olmaz" demeyin — taramalar otomatik ve kitlesel yapılıyor.

WAF kalıcı çözüm değildir: Web uygulama güvenlik duvarı kuralları saldırıyı yavaşlatabilir ama PHP ekibi açıkça söylüyor: bilinen bir hafifletme (mitigation) yok, tek kalıcı çözüm güvenli sürüme güncellemektir.

En yüksek risk mod_php'da: Uygulama kodu hiç çalışmadan, tek bir kimlik doğrulamasız istekle tetiklenebilen istismar gösterildi. Apache + mod_php kullananlar güncellemeyi en öne almalı.

Önce sızıntı kontrolü, sonra yama: Açık bir süredir biliniyor olabilir; güncellemeden önce bilinmeyen dosyalar, yeni kullanıcılar, şüpheli zamanlanmış görevler ve web kabuğu (webshell) izlerini kontrol edin. Yama, önceden yerleşmiş bir arka kapıyı temizlemez.

Gömülü PHP'yi unutmayın: Kendi PHP kurulumunuz olmasa bile paneller, hazır cihaz yazılımları ve üçüncü parti ürünler içinde PHP gelebilir. Üreticinizin duyurusunu kontrol edin.

PHP 8.1 ve altı için resmi yama yok: Bu sürümler ömrünü doldurdu. Dağıtımınız backport yayınlamıyorsa desteklenen sürüme geçiş şart; "çalışıyor, dokunmayalım" artık bir güvenlik borcudur.

Güncelledikten sonra worker'ları yeniden başlatın: PHP-FPM / web sunucusu süreçleri eski kodu bellekte tutar. Sürümü php -v ile ve gerçek web isteği üzerinden doğrulayın; gerekirse servisleri tamamen yeniden başlatın.

Remi deposu kullanıcıları dikkat: rpms.remirepo.net, yayın günü güncelleme sunamayacağını duyurdu; dağıtım paketlerine geçmeniz veya kaynaktan derlemeniz öneriliyor.

İRCOM tarafında durum

Yönettiğimiz altyapılarda PHP çalıştıran servislerin envanterini çıkardık ve güvenli sürümlere geçişi önceliklendirdik. Bu site (ircom.com.tr) bilinçli olarak statik HTML ile yayınlanıyor: PHP çalıştırmadığı için bu açıktan etkilenmiyor. Bakım anlaşmalı müşterilerimiz için ek bir işleme gerek yok; süreç tarafımızca takip ediliyor. Kendi sunucunuzu kendiniz yönetiyorsanız ve emin değilseniz bize yazın, birlikte kontrol edelim.

Kaynaklar

← Blog'a dön • Güncelleme için destek isteyin →