PHP Kritik Güvenlik Açığı php2shell: Ne Yapmalısınız?

PHP'nin 21 Ekim 2026 tarihli resmî duyurusuna göre PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri, kimlik doğrulaması olmadan uzaktan kod çalıştırmaya izin verebilen iki kritik açığı düzeltiyor. İkisi de CVSS v4.0 ölçeğinde 9,2 puan aldı; bu, açığın ne kadar tehlikeli sayıldığını gösteren standart bir puanlamadır. Uzaktan kod çalıştırma, bir saldırganın sunucuda web işçisi hesabının yetkileriyle komut işletebilmesi demektir. GitHub danışmanlıklarına göre ikinci açıkta bellek sızdırma da doğrulandı.

Etkilenen, web isteği karşılayan tüm PHP kurulumları: PHP-FPM, Apache ile mod_php, php-cgi, FrankenPHP ve LiteSpeed. Risk en yüksek mod_php'de; kimliksiz tek bir isteğin, uygulama kodu hiç çalışmadan saldırıyı tetikleyebildiği gösterildi. Amazon Threat Intelligence'ın 21 Ekim tarihli yazısına göre bal küpü ağı ilk istismar denemesini 17 Ekim'de, kamuya açıklanmadan dört gün önce gördü. SecurityWeek'in aktardığına göre watchTowr, dolaşan kavram kanıtlarının henüz uzaktan kod çalıştırmaya ulaşmadığını söylüyor. Yani denemeler var, başarı kanıtı sınırlı; bu belirsizlik beklemek için gerekçe sayılmaz.

Siteniz PHP ile çalışıyorsa etkileniyor sayın. Anadolu Ajansı'nın aktardığına göre FBI, PHP'nin web sitelerinin yaklaşık %70'inde kullanıldığını tahmin ediyor. CISA'ya göre PHP başka yazılımların içine gömülü de olabilir ve görünmeyebilir. Sitenizin neyle çalıştığından emin değilseniz teknoloji tespiti aracımız dışarıdan bir ilk fikir verir; ama sürümü kesinleştirmesini beklemeyin.

Sürümü kesin öğrenmek için WordPress.org'un tarif ettiği yolu izleyin: WordPress panelinde Araçlar, Site Sağlığı, Bilgi, Sunucu sekmesine bakın. Hosting panelleri de çoğunlukla PHP sürümünü gösterir. WordPress dışı sitelerde bunu yazılımcınız ya da sağlayıcınız söylemelidir. Sürümünüz kendi hattınızdaki numaranın altındaysa (8.2.35, 8.3.36, 8.4.27 ya da 8.5.12), GitHub danışmanlıklarına göre etkileniyorsunuz.

Paylaşımlı hostingde sunucuyu sağlayıcı yönetir; sizin işiniz ona yazılı sormaktır: bu açıklar için PHP güncellendi mi, hangi sürümdeyim? WordPress.org'a göre sağlayıcıların durumu saat saat değişti: bazıları yamaladı, bazıları WAF ile koruduğunu söyledi, bazıları devam ediyordu. WAF, siteye gelen istekleri süzen güvenlik duvarıdır. Cevap «korunuyoruz» ise hangi sürüme çıkıldığını sorun.

cPanel'in sürüm notlarına göre EasyApache 4 25.91 ea-php74'ten ea-php85'e kadar iki açığı düzeltiyor, 25.92 ise ea-php74, ea-php80 ve ea-php81 paketlerini yeniden derliyor. Bu paketler genellikle otomatik güncellemeyle gelir; ama bu bizim yorumumuz, sunucu yöneticisi WHM'de sürümleri doğrulamalı. Plesk kullanıyorsanız aynı soru geçerli: sağlayıcınızdan paket adını ve sürüm numarasını isteyin. Kendi sunucunuz varsa Laravel Forge'un bilgi bankasına göre otomatik güvenlik güncellemeleri PHP'yi yamalamaz; her sunucuda PHP ayrıca güncellenmeli. PHP projesi de Linux dağıtımlarının yamayı önceden aldığını belirtip «sağlayıcınızın paketlerini kontrol edin» diyor.

PHP 8.1 ve öncesi PHP projesinden güncelleme almıyor. Güvenlik ekibi 7.4, 8.0 ve 8.1 için asgari kaynak yamaları sağladı ve bazı dağıtımlar geri taşıma yapıyor; ama bunlar sizin hostunuzun paketine girmiş olmayabilir. WordPress.org da 8.2 öncesi PHP'nin güvenlik güncellemesi almadığını hatırlatıyor. VulnCheck'in aktardığına göre internete açık 2,6 milyondan fazla PHP sunucusunun en az 1 milyonu ömrünü tamamlamış sürümde çalışıyor.

CISA, güncellenemeyen ya da 8.1 ve altındaki sistemlerin çevrim dışına alınmasını öneriyor. WordPress.org da İngiltere NCSC'ye atıfla, sunucuyu siz yönetiyorsanız yükseltene kadar çevrim dışına almayı düşünmenizi söylüyor. Sitenizden gelir gelmiyorsa, örneğin yalnızca tanıtım sayfasıysa, bu gerçekçi bir seçenektir. PHP 8.2 ise 31 Aralık 2026'da ömrünü tamamlıyor; bugün 8.2.35'e çıkmak sizi kısa süre idare eder, sürüm planınızı şimdiden yapın.

PHP duyurusu açık: yalnız güncelleme tam çözümdür; geçici önlemler belirli saldırı yollarına maruziyeti azaltır ama kurulumu güvenli yapmaz. GitHub danışmanlığı da yamalı sürüme çıkmayı tek tam önlem olarak adlandırıyor. İkinci açık, iki isteğin aynı işçiye düşmesini gerektiriyor; çok işçi ve işçi yenileme başarı oranını düşürür ama riski ortadan kaldırmaz, yapılandırmayla tam önlem yok. CISA geçici olarak WAF öneriyor; geçici sözcüğü burada önemli.

Aşağıdakiler PHP duyurusunun saydığı önlemlerdir ve bunları siz değil sunucu yöneticiniz uygulamalıdır. Duyuru ayrıca saldırganın tetikleyebildiği ölümcül hataları ve zaman aşımlarını düzeltmeyi, istek başına uygulanan geçersiz ya da kullanımdan kalkmış INI ayarlarını kaldırmayı da sayıyor. Codeable'a göre WordPress session.upload_progress özelliğini kullanmıyor; yine de diğer uygulamalar için yöneticinize sorun.

• memory_limit=-1, uygulamanın geçersiz kılamayacağı biçimde (php_admin_value ile)
• Düşük post_max_size: dosya yüklemesi yoksa 8M, varsa 32M; upload_max_filesize bunun altında olmalı
• session.upload_progress.enabled=0 ve tüm işçileri yeniden başlatma; php.ini ya da havuz ayarıyla, ini_set ya da .user.ini ile değil
• PHP 8.5'te fatal_error_backtraces=0
• RLIMIT_AS ve RLIMIT_DATA kullanmayın, açığı tetikleyebilir

Amazon Threat Intelligence, incelemenin en az 17 Ekim'den başlatılmasını söylüyor, çünkü ilk deneme o gün görüldü. Göstergeler: form yüklemelerinde PHP_SESSION_UPLOAD_PROGRESS dizgisi içeren POST istekleri, web sunucusu günlüklerinde şüpheli kayıtlar, beklenmeyen süreç çalışması ya da dosya değişikliği. Sağlayıcınızdan ya da yöneticinizden bu izleri aramasını isteyin. CISA ayrıca kabuk açan ya da araç indiren PHP işçi süreçlerini izlemeyi öneriyor. Güvenlik denetimi aracımız dışarıdan görünen temel ayarlara bakar; sunucudaki günlüklerin ve dosyaların yerini tutmaz.

İkinci konu uzun süreli süreçler. Laravel Forge'un bilgi bankasına göre güncelleme PHP-FPM'i yeniden başlatır, ama komut satırından başlatılmış kuyruk işçileri, Horizon ve Octane yeniden başlatılana kadar eski PHP ile çalışmaya devam eder. Doğrulama için sunucuda php8.4 -v ve php-fpm8.4 -v çalıştırılır (8.4 kullanıyorsanız). Qualys'a göre php -v'nin döndürdüğü sürüm, web isteklerini karşılayandan farklı olabilir. Geçici olarak memory_limit=-1 verdiyseniz sonlu bir değere geri alın. Yukarıdaki izlerden birine rastlarsanız ya da emin olamıyorsanız veritabanı parolalarını, API anahtarlarını ve yönetici şifrelerini değiştirmeyi yöneticinizle konuşun; bu kaynaklarda geçmeyen, genel bir temizlik ilkesidir.

Üç hata öne çıkıyor. Bunlardan kaçınmak, çoğu işletme için güncellemenin kendisi kadar önemli.

Amazon, 7 ya da 30 günlük yama süresinin artık var olmayan bir gecikmeyi varsaydığını, sürecin saatlerle ölçülmesi gerektiğini yazıyor. PHP Foundation ise düzeltmenin Ağustos'tan beri hazırlandığını, 20 Ekim'de CVE kimliklerinin yanlış bilgiyle sızdığını ve sürümün bir gün öne çekildiğini anlattı. Çıkarılacak ders sade: sitenizin altındaki yazılımın kimde olduğunu, kimin güncellediğini ve kimi arayacağınızı yazılı tutun, ömrü dolan sürümleri takvime bağlayın.

• Eklenti, tema ya da WordPress güncellemesini yeterli sanmak: WordPress.org'a göre bu sorunlar için WordPress güncellemesi gerekmiyor ve planlanmıyor; eklenti ya da tema güncellemek korumaz
• php -v çıktısına güvenmek: komut satırındaki sürüm, web isteklerini karşılayan kurulumdan farklı olabilir
• WAF'ı çözüm sanmak: CISA onu geçici önlem olarak sayıyor; sağlayıcının «WAF ile koruyoruz» demesi sürümün güncel olduğunu göstermez