PHP2Shell için yama yetmez: PHP çalışanlarını da yeniden başlatın

Türkiye’de PHP hizmeti yönetenler için PHP2Shell düzeltmesini kurmak müdahalenin sonu değil: web isteklerini karşılayan PHP çalışanları da yenilenmeli. TMMOB Bilgisayar Mühendisleri Odası, 23 Ekim 2026 açıklamasında kamu kurumlarını, özel kuruluşları ve hizmet sağlayıcılarını etkilenen sistemleri belirlemeye, yamaları uygulamaya, çalışan süreçleri yeniden başlatmaya ve sonucu doğrulamaya çağırdı. CVE-2026-109618 ve CVE-2026-109619 açıkları, Türkiye’deki çevrimiçi hizmetlerin sürekliliği ve verilerin korunması açısından da risk oluşturuyor.

PHP düzeltmeleri yayımlandı; açıklar, istek işleme sırasında bellek bozulması üzerinden kimlik doğrulaması olmadan uzaktan kod çalıştırılmasına yol açabiliyor. Plesk’in 22 Ekim’de güncellediği sürüm tablosuna göre 21 Ekim’de çıkan yamalarla PHP 8.2.34 ve altı için 8.2.35, 8.3.35 ve altı için 8.3.36, 8.4.26 ve altı için 8.4.27, 8.5.11 ve altı için 8.5.12 gerekiyor; Plesk’in Linux paketlerinde 7.4.33, 8.0.30 ve 8.1.34 ise aynı sürüm numarasını koruyan yeni derlemelerle düzeltiliyor. Kurulu paketin numarası kadar, web trafiğine yanıt veren hizmetin o yeni derlemeyi kullanması da kontrol edilmeli.

Etkilenen sürüm hangi kaynaktan geliyor?

Bu sürüm eşikleri Plesk’in dağıttığı PHP için açık bir karşılaştırma sunuyor. Linux dağıtımının kendi paketi, Plesk işleyicisi ve uygulama imajına gömülü PHP ayrı kaynaklar olduğundan birindeki güncelleme diğerini kendiliğinden değiştirmez. Sunucuda birden fazla site farklı PHP işleyicileri kullanıyorsa her site kendi seçili sürümü üzerinden değerlendirilir.

PHP projesi eski dallara düzenli güvenlik sürümü yayımlamıyor; bazı dağıtımlar ve uzun süreli destek sağlayıcıları düzeltmeyi eski paketlere taşıyabiliyor. Bu durumda düşük görünen sürüm numarası tek başına açığın sürdüğünü kanıtlamaz: paketin üreticisi, güvenlik bildirimi ve derleme kaydı birlikte okunmalı. Eski Linux paketlerinde derleme tarihinin belirleyici olması, yalnızca sürüm numarasına dayanan taramaların neden eksik sonuç verebileceğinin somut örneği.

Plesk Obsidian kullananlarda panelin kendi PHP motoru ile sitelere atanmış PHP işleyicileri ayrı bileşenlerdir. Paneli güncellemek, barındırılan bütün sitelerin işleyicisini yükseltmez; sitenin PHP işleyicisini güncellemek de panel motorunu değiştirmez. Windows için yayımlanan yamalı liste desteklenen yeni dalları kapsarken eski Linux dallarında yeni derlemenin tarihi ayrıca karşılaştırılmalı.

PHP-FPM, mod_php ve konteynerde risk neden farklı?

İnternetten gelen isteği hangi PHP çalışma biçiminin işlediği, istismar olasılığını ve yenilenecek hizmeti değiştirir. Red Hat’ın 23 Ekim’de güncellenen güvenlik bülteni, varsayılan Apache mod_php kurulumlarını daha yüksek riskli değerlendiriyor; PHP-FPM çalışanlarının erken başlatma hatalarında çıkmasının uzaktan kod çalıştırmayı pratikte zorlaştırdığını, Red Hat Enterprise Linux 7 paketinin ise bu iki açıktan yalnızca CVE-2026-109619’dan etkilendiğini belirtiyor. Bu ayrım dağıtımın paketine ve kurulum biçimine ait; başka bir sistemin güvenli olduğu sonucunu vermez.

Açıkların mekanizması da çalışan süreçlerin önemini gösteriyor. Bir yolda istek ayrıştırılırken bellek ayırma başarısız oluyor ve temizleme işlemi tamamlanmamış durumla karşılaşıyor; diğerinde serbest bırakılmış istek belleğine işaret eden bilgi daha sonra yeniden kullanılabiliyor. Aynı çalışan art arda istek alıyorsa belleğindeki eski durum, disk üzerindeki paketin yenilenmiş görünmesinden ayrı incelenmeli. Yapılandırma değişikliğinden sonra yalnızca yeniden yükleme yapmak da bütün eski çalışanların çıktığını garanti etmiyor.

• PHP-FPM: Sanal sunucunun bağlandığı havuzu ve o havuzun kullandığı paket kaynağını belirleyin. Düzeltmeyi kurduktan sonra ilgili PHP-FPM hizmetini yeniden başlatın; birden çok havuz veya sürüm varsa her birinin yeni çalışanlar açtığını doğrulayın.
• Apache mod_php: PHP kodu Apache sürecinin içinde çalışır. Paketi güncelledikten sonra Apache hizmetini yeniden başlatın; yalnızca PHP-FPM hizmetine işlem yapmak bu kurulumdaki çalışan modülü yenilemez.
• Plesk: Panel motoru ile sitelerin PHP işleyicilerini ayrı kontrol edin. Sitenin seçili işleyicisi, paket kaynağı ve derleme bilgisi beklenen düzeltmeyle eşleşmeli; varsayılan komut satırı PHP’si bu bilgilerin yerine geçmez.
• Konteyner: Düzeltilmiş PHP içeren temel imajla uygulama imajını yeniden oluşturun; çalışan konteyneri veya pod’u yeni örnekle değiştirin. Depoda yeni imaj bulunması, çalışan eski örneğin belleğindeki kodu değiştirmez.

Güncellemenin web hizmetine geçtiği nasıl anlaşılır?

Değişiklik, yalnızca paket yöneticisinin başarılı çıkışıyla değil, gerçek isteği karşılayan PHP ortamının doğrulanmasıyla tamamlanır. Aynı makinedeki komut satırı ikilisi, Apache modülü, PHP-FPM havuzları ve Plesk işleyicileri farklı sürümler kullanabilir. Bu nedenle php -v yararlı bir başlangıçtır; ziyaretçinin ulaştığı PHP sürecinin sürümünü tek başına göstermez.

1. İnternete açık uygulamaları, alt alan adlarını, dış hizmet sağlayıcılarını ve her birinin kullandığı PHP işleyicisini envantere alın. Paket kaynağını, mevcut derlemeyi ve geri dönüş yolunu kaydedin; çoklu havuzları veya eski konteyner örneklerini kapsam dışında bırakmayın.
2. Kurulu bileşeni sağlayan kanaldaki güvenlik paketini uygulayın. Dağıtımın geri taşıdığı düzeltme varsa yalnızca ana sürüm numarasına bakmak yerine ilgili güvenlik bildirimini ve paket sürümünü eşleştirin; Plesk işleyicisi için dağıtım paketini otomatik olarak eşdeğer saymayın.
3. İstekleri karşılayan süreçleri yenileyin: PHP-FPM hizmetini veya mod_php kullanan Apache’yi yeniden başlatın; konteynerde eski örneği değiştirin. Hizmetin yeniden açıldığını, beklenen çalışanların oluştuğunu ve eski süreçlerin istek kabul etmediğini kontrol edin.
4. Web isteğinin kullandığı işleyici ve derlemeyi, sağlayıcının düzeltilmiş sürümüyle karşılaştırın. Uygulamanın temel işlevlerini ve hizmet günlüklerini kontrol edin; yalnızca ana sayfanın açılması, başka bir sanal sunucunun veya havuzun da güncellendiğini göstermez.

Yama hemen kurulamayacaksa erişimi daraltmak ve belirli yapılandırma yollarını kapatmak geçici risk azaltabilir. Oturum yükleme ilerlemesini kapatma gibi ayarlar istek ayrıştırılmadan önce etkin olmalı ve mevcut çalışanlar yenilenmeli; bu değişiklikler düzeltmenin yerini tutmaz. İnternete açık bir hizmette son kontrol, yeni paketin diskte bulunması değil, düzeltilmiş PHP sürecinin gerçek trafiği karşılamasıdır.

Ayrıca okuyun:

• PaperCut açığı saldırıda: Üçüncü acil yama önceki ikisinin yerini aldı
• PaperCut’ta üçüncü acil yama: İlk iki sürüm artık yeterli değil
• Kuantum sonrası TLS pilotunda yedi kök var, hiçbiri üretim için değil