Uzun yıllardır PHP kod yazarı ve PHP siteler geliştiren biri olarak, PHP2Shell zafiyeti hakkında çoğu platformda bahsedilmeyen bir noktaya değinmek istiyorum.
Öncelikle PHP2Shell; PHP altyapısında keşfedilen ve sırasıyla CVE-2026-109618 ile CVE-2026-109619 kodlarıyla duyurulan iki kritik güvenlik açığına verilen ortak isimdir. CVSS skoru 9.2 (Kritik) seviyesinde olan oldukça ciddi bir zafiyettir.
Hatta bazı devletler sitelerini geçici olarak kapattı. Dünyadaki tüm web sitelerinin yaklaşık %42'si PHP altyapısını kullanıyor; yani etkilenen kesim oldukça büyük. Bu açığın kapatılması için yayınlanan yamalı PHP sürümleri ise şunlardır:
PHP 8.5.12 (veya üzeri)
PHP 8.4.27 (veya üzeri)
PHP 8.3.36 (veya üzeri)
PHP 8.2.35 (veya üzeri)
Gelelim asıl anlatacağım kısımlara (ki Levent Pekcan'ın da gündemde buna yer vermesini isterim):
Dış dünyaya yayın yapan sunucuların PHP sürümlerini yukarıda belirttiğim sürümlere yükseltmesinin yeterli olduğu söyleniyor. Ancak burada pek çok yayıncının ve habercinin göz ardı ettiği bir durum var: Kişisel web sitelerinin PHP sürüm uyumluluğu.
Örneğin; PHP 5.6.40 sürümünde çalışan elinizdeki herhangi bir PHP scriptini (betiğini/yazılımını) alıp doğrudan PHP 8.2 - 8.5 arası bir sürüme geçirdiğinizde, yüksek ihtimalle çalışmayacak ve ekranda birçok hata verecektir.
WordPress veya Joomla gibi hazır altyapı kullanan siteleri bu durumun dışında tutuyorum; zira onlarda yönetim panelinden güncelleme yapmak genellikle yeterli oluyor. Ancak geçmişte yazılmış özel PHP yazılımları, sunucunun PHP sürümü yükseltildiğinde büyük sorun yaşayacak ve çeşitli hatalar verecektir.
Bir de işin Hosting boyutu var (burada hemen Güzel.Net'in de reklamını yapmış olalım :). Hosting firmaları çoğunlukla güncel sürümleri barındırır; hatta cPanel gibi paneller üzerinden kullanıcıya PHP sürüm seçeneği sunarlar. Yani kullanıcı, güncel sürüm PHP 8.x iken panelden PHP 5.6.40 sürümünü de seçip kullanabilir.
İşte asıl sorun burada kopacak. Evet, sitelerin çoğu WordPress ama WordPress olmayan binlerce site de mevcut. Sunucu firmaları, müşterilerin ellerindeki eski yazılımların / scriptlerin çalışabilmesi ve uyumluluk adına PHP 8.x altındaki sürümleri şimdiye kadar sunmaya devam ediyorlardı.
Fakat PHP ekibi 8.x altındaki sürümler için yamalı yeni bir sürüm çıkarmadığına göre, sunucu firmaları bu eski sürümleri sunmaya devam edecekler mi? Yoksa "Açık var, bu nedenle artık sadece PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 üzeri sürümleri destekliyoruz" mu diyecekler?
İşte burada ciddi bir kriz yaşanacak. Çoğu kişi eski PHP yazılımını güncelleyemeyecek. Hem kullanıcılar hem de hosting firmaları için oldukça karmaşık ve zorlu bir süreç olacak. Burada benim de emin olamadığım bir konu var: Acaba güvenlik duvarı (WAF/Firewall) cihazlarına eklenecek yeni kurallarla bu saldırı biçimi bertaraf edilebilir mi? Orası henüz meçhul...
Bir de işin PHP topluluğu/geliştirici tarafı var: Neden böyle bir açığı bu şekilde duyurdular? Bu güncellemeyi daha sessiz bir süreçle yönetselerdi PHP'nin saygınlığı açısından çok daha iyi olurdu.
Tabii ki PHP yine bizim gözümüzde PHP'dir; işlerimizi PHP ile yapmaya ve artık 8.x sürümlerine uygun kod yazmaya devam edeceğiz. Şunu da belirtmek gerekir ki; açık kaynak kodlu bir yazılımda her zaman açık çıkabilir. Sonuçta PHP çekirdeği ve yorumlayıcısına ait kaynak kodları GitHub'da herkese açık. Asıl çoğunluğun fark etmediği ve daha tehlikeli olan durum, ASP.NET gibi kapalı kaynak kodlu sistemlerdir.
"Neden böyle bir açığı bu şekilde duyurdular? Bu güncellemeyi daha sessiz bir süreçle yönetselerdi PHP'nin saygınlığı açısından çok daha iyi olurdu." https://teknoseyir.com/durum/1813189
"PHP'nin saygınlığı..." kısmında ben de biraz tereddüt ettim. Her sürümünün kendi kafasına göre yola devam ettiğini anladığımda (PHP4'ten 5'e geçiş dönemiydi sanırım) benim gözümde bir saygınlığı kalmamıştı, sadece daha iyisi olmadığı için kabullenilen bir sistem olduğunu anlamıştım PHP'nin. Hala da öyle düşünüyorum. Geriye uyumluluk diye bir şeyden haberin olmazsa, her sürümde eski fonksiyonları çatır çatır kesip atarsan, insanlar PHP 7'yi bırak, PHP 4'de bile mahsur kalır. Şu son sorunda da anlaşıldı profesyonel gözüken bir operasyonun nasıl tamamen amatör olduğu.
@leventp Meltdown ve Spectre krizleri bilişim tarihinin en sarsıcı donanım felaketleriydi; etkilenen işlemci oranı %90'ın üzerindeydi. Şu an PHP tarafında yaşananların biraz fazla sansasyonel bir haber hâline getirildiğini düşünüyorum.
Sürüm geçişi konusundaki tespitinize hak veriyorum; ben de zamanında ereg() / eregi() fonksiyonlarının bırakılıp preg_match'e geçilmesi sürecinde az sorun yaşamadım.
@nefrit Valla ben bir siteyi komple çöpe attım sayılır o yüzden.
@leventp Bizim 16-17 yıldır kullandığımız bir program var. PHP 5.4 ile yazıldı. Sonraki versiyonlarında uygulama çöktüğü için mecbur bu uygulamanın bulunduğu site PHP 5.4 ile kullanılıyor. Bu yüzden aynı sitede güncel sistem kullanamıyoruz ve güvenlik açıklarıyla kabul etmek zorundayız. PHP gibi bir programlama dilinde geriye dönük uyumluluk olmaması kadar saçma bir şey olamaz.
@mannequin Emin olun onbinlerce, belki yüzbinlerce web sitesi aynı halde, eski PHP sürümlerine esir olmuş durumda.
@nefrit Unofficial yamalar çıkacaktır büyük ihtimalle. O şekilde güncelleyip kullanırlar yada o bahsi geçen ayarı php.ini ile kapatırlar sunucu boyutuyla.
O şekilde sorunun çözüldüğü teyit edilmiş bi hosting firması tarafından.
Ben de bir sysadmin olarak olayın OS kısmındaki sorunlardan bahsedeyim. @mannequin gibi bazı arkadaşların da bahsettiği üzere geriye uyumluluk PHP ve Perl dünyasında büyük bir baş ağrısı. Elimizdeki bir uygulama daha üst PHP sürümlerinde çalışmıyor diye, firewall ve yapabildiğimiz tüm güvenlik sıkılaştırmalarını uygulayarak CentOS 6'da PHP 5.3.3 ile ayakta tutmaya çalıştığımız sunucu var. Yine CentOS 7 üzerinde PHP 7.2.24'te takılı kalmış bir dünya sunucu hala duruyor. Aktif PHP kullanan ana sunucularımız ise AlmaLinux 9 kullanıyor; resmi PHP patch'i gelmese bile Alma ekibini gerçekten kutlamak lazım, Red Hat ve Rocky'nin yapmadığını yapıp 8.0.30 için bile backport edilmiş güvenlik yaması çıkardılar. RemiRepo gibi ek 3. parti kaynaklar kullanmıyorsanız bu sektörde işiniz gerçekten çok zor.
RedHat tabanlı sistemler için güncel durum ve yamalar ile ilgili detaylar burada:
https://github.com/nsrg-fmlorg/php-cve-2026-109618