PHP2Shell'de asıl tuzak: php -v eski sürümü gösteriyor ama sunucunuz yamalı olabilir (ya da tam tersi)

PHP2Shell'in ilk iki gününde gündem netti: iki kritik açık (CVE-2026-109618 ve CVE-2026-109619), 21 Ekim'de çıkan 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri ve önlem olarak kapanan sitelerin uzun listesi. Bu yazıda o hikâyeyi tekrar anlatmayacağım. Bugün daha sinsi bir soruna odaklanmak istiyorum: Sunucunuzun yamalı olup olmadığını sürüm numarasına bakarak anlayamayabilirsiniz. Özellikle PHP 8.1 ve öncesini kullanıyorsanız, bu ayrıntı "güvendeyim" ile "açığım" arasındaki farkı belirliyor.

Kısa hatırlatma: Neden bu kadar ciddi?

İki açık da CVSS v4.0'a göre 9.2 puan alıyor ve kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya imkân tanıyor. Datadog'un analizine göre saldırı, PHP isteği uygulama koduna ulaşmadan önce işlediği aşamada gerçekleşiyor. Yani uygulamanızdaki giriş kontrolleri, framework'ünüzün middleware'i ya da WordPress eklentiniz bu noktada devreye bile girmiyor.

• CVE-2026-109618: İstek hazırlanırken bellek sınırı aşılınca yarım kalan bir veri yapısı, temizlik sırasında geçerliymiş gibi işleniyor.
• CVE-2026-109619: Bir isteğe ait durum bilgisi, bellek serbest bırakıldıktan sonra da yaşamaya devam ediyor ve aynı worker'ın sonraki isteği bu kalıntıyı kullanabiliyor.

PHP'nin uyarısına göre web isteği sunan her kurulum kapsamda: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed ve FrankenPHP. En riskli yapılandırma ise mod_php.

Saldırı iddiaları: Tablo hâlâ karışık

Aktif istismar konusundaki haberler birbiriyle çelişiyor ve bunu dürüstçe söylemek gerekiyor. Amazon, 17 Ekim'de, yani açıklamadan dört gün önce honeypot ağında bir istismar denemesi gördüğünü bildirdi. watchTowr 21 Ekim'den itibaren kendi tuzak sistemlerinde istismar gözlemlediğini söylüyor. Öte yandan CISA, 21 Ekim itibarıyla istismar görmediğini belirtti ve her iki CVE de henüz KEV kataloğunda değil.

En öğretici örnek Sophos'tan geldi. Şirket 22 Ekim'de başarılı bir istismar tespit ettiğini duyurdu, birkaç saat sonra bu iddiayı geri çekti: telemetride yalnızca taramalar ve başarısız denemeler vardı. Sophos ayrıca kendi ekibinin çalışan bir exploit üretmekte zorlandığını, başarının mimariye, PHP sürümüne ve yapılandırmaya bağlı olduğunu yazdı.

Benim çıkarımım şu: "Exploit zor, demek ki acelem yok" diye düşünmek yanlış olur. Geniş çaplı tarama zaten başladı ve Wiz araştırmacıları yapay zeka modellerinin exploit geliştirme eşiğini ciddi şekilde düşürdüğünü söylüyor. Zor olan bir şey, birkaç gün içinde kolay hâle gelebilir.

Asıl mesele: Sürüm numarası yalan söyleyebilir

PHP projesi 7.4, 8.0 ve 8.1 için numaralı bir sürüm yayımlamadı. Bunun yerine php-src deposunda yalnızca kaynak kod olarak "minimal backport" yamaları paylaştı. Tarball yok, Windows binary'si yok, sürüm artışı yok. Bu yamalar kaynaktan derleyenler ve LTS sağlayıcısı olmayanlar için düşünülmüş.

Dağıtımlar ve kontrol panelleri ise yamaları çoğunlukla mevcut sürüm numarasını koruyarak dağıtıyor. 22 Ekim'deki durum derlemelerinden birkaç örnek:

• Ubuntu 22.04: PHP 8.1 paketi yine 8.1.2 olarak görünüyor ama paket revizyonu değişti (USN-8948-1).
• Ubuntu 24.04: PHP 8.3 paketi 8.3.6 olarak duruyor, 8.3.36'ya yükselmedi.
• Plesk: 7.4.33, 8.0.30 ve 8.1.34 sürümleri aynı numarayla geldi; değişen tek şey derleme tarihi.
• cPanel EasyApache 4 ve DirectAdmin: Eski sürümler için backport yayımladılar, yine aynı sürüm numarasıyla.

Yani php -v çıktısında "8.1.2" görmek sizi tek başına ne korkutmalı ne de rahatlatmalı. Tersi de mümkün: Komut satırındaki php yamalı olabilir ama sitenizi sunan PHP-FPM havuzu farklı bir paketten geliyor olabilir.

Adım adım kontrol

1. Siteyi gerçekte hangi PHP'nin sunduğunu bulun

CLI, PHP-FPM, mod_php ve LiteSpeed farklı paketlerden gelebilir. Aynı sunucuda birden fazla PHP sürümü yan yana kurulu olabilir. Panel kullanıyorsanız her alan adının hangi sürümü kullandığına bakın.

2. Paket sürümünü ve değişiklik kaydını kontrol edin

# Debian / Ubuntu
dpkg -l 'php*' | grep ^ii
apt-cache policy php8.1-fpm

# RHEL / AlmaLinux / Rocky
rpm -q --changelog php | grep CVE-2026-10961

Aradığınız şey değişiklik kaydında bu iki CVE'nin geçmesi ya da dağıtımınızın güvenlik bülteninde (USN, DSA, RHSA vb.) listelenen paket revizyonu. Plesk'in eski sürümlerinde php -i çıktısındaki derleme tarihine bakmak gerekiyor.

3. Worker'ları yeniden başlatın

Paketi güncellemek yetmez. Çalışan PHP-FPM havuzları, Apache süreçleri ve kuyruk işçileri, siz yeniden başlatana kadar eski kodu bellekte tutar. Docker kullanıyorsanız imajı yeniden derleyip konteynerleri değiştirmeniz gerekir.

4. Paylaşımlı hosting kullanıyorsanız sağlayıcınıza sorun

Paylaşımlı hostingde PHP'yi siz yönetmiyorsunuz. Sağlayıcınıza hangi CloudLinux, cPanel veya Plesk güncellemesinin uygulandığını ve sitenizin seçili PHP sürümünün kapsamda olup olmadığını sorun. Panelden 8.1 veya daha eski bir sürüm seçtiyseniz, bu fırsatı desteklenen bir sürüme geçmek için kullanın.

8.1 ve öncesini kullananlar için seçenekler

Herkes için yol aynı değil:

• Dağıtım veya panel backport'u: Ubuntu Pro, Red Hat ailesi, TuxCare, Sury deposu, cPanel, Plesk, DirectAdmin ve CloudLinux kendi yamalarını yayımladı. En pratik yol bu.
• Hiç yama gelmeyecek platformlar: Derlemelere göre Amazon Linux'taki bazı 8.1 paketleri, Homebrew'daki php@8.1 ve resmi Docker imajlarının 8.1 etiketleri için düzeltme yok. Remi deposunda da 22 Ekim itibarıyla güncelleme görünmüyordu.
• Kaynaktan derleme: PHP'nin minimal backport yamasını uygulayabilirsiniz, ama bu bakımı sizin üstlenmeniz anlamına gelir.
• PHP 7.3 ve öncesi: Resmi bir düzeltme yolu yok. Tek gerçek çözüm yükseltme.

Geçici önlemler (session.upload_progress.enabled=0, istek boyutu sınırları, Cloudflare'in WAF kuralları) yalnızca bazı saldırı yollarını kapatıyor. PHP ekibi hiçbir yapılandırma değişikliğinin tam koruma sağlamadığını açıkça söylüyor.

Neden önemli?

Türkiye'de hâlâ çok sayıda proje eski PHP sürümlerinde çalışıyor: yıllardır dokunulmamış kurumsal paneller, ajansların teslim edip unuttuğu WordPress siteleri, "çalışıyorsa elleme" mantığıyla bırakılmış sunucular. PHP2Shell bu teknik borcun faturasını kesiyor. PHP 8.2'nin güvenlik desteğinin de 31 Aralık 2026'da bittiğini hatırlatayım; yani bugün 8.2'ye geçen ekip birkaç ay sonra aynı soruyla tekrar karşılaşacak.

Kısa vadede yapılacak iş belli: hangi PHP'nin sitenizi sunduğunu bulun, paketin gerçekten yamalı olduğunu değişiklik kaydından doğrulayın, worker'ları yeniden başlatın. Orta vadede ise envanterinizdeki her PHP kurulumu için bir yükseltme takvimi çıkarın. Bir sonraki kritik açıkta "bizim sürüme yama gelecek mi?" sorusunu sormak zorunda kalmamak en iyi savunma.