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?" belki de kendileri altından kalkamayacaklarını düşündükleri için orta sahaya adam çağırmak istemişlerdir.
PHPnin saygınlığı azaldı, ama bu 'kral çıplak' denilmesi şeklinde oldu, herşey gizli kalsaydı, PHP sahte saygınlığını sürdürseydi daha mı iyi olurdu? Uzaktan bakan birisi olarak yazıyorum. PHP ile bağlantım birkaç WordPress sitem olması ama teknolojinin de çok uzağında değilim.
Öncelikle niye sadece 8 sürümü aktif destekleniyor? 5 sürümüne yama niye çıkmıyor? Eğer ürün kullanılıyorsa ve kullanılmasının makul nedeni varsa desteklemek lazım. Derseniz ki açık kaynak, dondurmam kaymak, 2019da süresi doldu, işte durum ortada.
Bağlantılı olarak, neden PHP sürümleri bu kadar uyumsuz? PHP 8in PHP 5.6 kodunu uyumlu düzgün şekilde çalıştırması lazım. Bu kadarcık bir geriye uyumluluk niye yapılmıyor? (2010da yazılmış bir uygulamayı bugün en son donanım ve yazılımla çalıştırabiliyorum - demek ki yapan yapıyor). Onu geçtim, bu yazıdan anladığım kadarıyla 8.2, 8.3, 8.4, 8.5 bile birbiriyle uyumsuz ki her birine ayrı güncelleme çıkıyor (aralarında 1 yıl varmış sadece). Sistem baştan yanlış kurulmuş yani. Sürekli birbiriyle uyumsuz aynı isimde (sadece versiyonu değişik, syntax'ı benzeyen) bir ürün çıkartmak ilginç. TPLink'in donanımı tümüyle farklı aynı model isminde ürünler çıkartması gibi.
Geriye uyumluluk konusunda kesinlikle haklısınız. "Sistem baştan yanlış kurulmuş yani" kısmına da güncellemeler / uyumluluk konusunda katılıyorum. PHP sürüm güncellemeleri yapılırken kesinlikle daha iyi bir geriye uyumluluk gözetilebilirdi.
Örneğin PHP'nin eski sürümlerinde çalışan, metin arama/eşleştirme için kullanılan ereg(), eregi() gibi fonksiyonlar vardı. PHP grubu bunlara "yavaş ve güvensiz" diyerek daha üst sürümlerde tamamen kaldırdı ve yerlerine preg_* (preg_match vb.) fonksiyonlarını getirdi. Tabii ki eski ereg() fonksiyonlarının arka plandaki kaynak kodları güncellenerek daha güvenli, hızlı ve fonksiyonel hâle getirilebilirdi; ancak güvenlik ve mimari standartlar ekibi bu köklü kesintiyi ve değişimi tercih etti.
PHP 8 sürümüne geçişte ise each() fonksiyonu kaldırıldı; bunlar sadece küçük örnekler. Açıkçası, geçmişteki basit web teknolojileri düşünüldüğünde PHP bugün artık sadece bir web dili olmanın ötesine geçti; kapalı gömülü sistemlerde kullanılabiliyor ve iki farklı yazılımın birbiriyle haberleşmesinde köprü görevini üstlenebiliyor.
Bir yanda PHP'nin geriye uyumlulukta yarattığı bu sancılı süreç, diğer yanda ise dilin eskiye nazaran çok daha güçlü ve kıvrak bir yapıya kavuştuğu gerçeği duruyor.
Benzer bir durum MAME oyunlarında da mevcut. MAME öylesine hantal bir yazılımdır ki, her çıkan yeni sürümde eskiden çalışan bazı oyun ROM'ları çalışmamaya başlar. Çünkü MAME, oyun ROM'larının içinde barındırması gereken dosyaları katı bir şekilde kendi hash listesiyle kontrol eder; ROM içinde eksik veya farklı bir dosya görürse o oyunu direkt "çalışmaz" olarak işaretler.
Oysa emülatörün içine devasa bir veri tabanı gömüp her sürümde mevcut ROM setlerini bozmak yerine, ROM'un içine önceden info.txt gibi basit bir bilgi dosyası koysalar ve emülatör; oyunun ismi, işlemcisi, çalışacağı kart ve içermesi gereken dosyalar gibi bilgileri buradan okusaydı, belki de hiçbir oyunda sürüm uyumsuzluğu sorunu yaşanmayacaktı.
Yani sizin "Bu kadarcık bir geriye uyumluluk niye yapılmıyor?" ve "Sistem baştan yanlış kurulmuş" sözleriniz, nedense konuyu PHP'den bir anda MAME'nin bu katı ve cezalandırıcı çalışma mantığına bağlamama neden oldu 🙂
@nefrit Cevap için teşekkürler. Elbette bazı şeylerin basit, kolay ve güzel çözümleri olsaydı, zaten yapılmış olurdu. Alınan her kararın avantajı - dezavantajı olmuştur, geriye bakarak doğru yanlış dememek, çok yermemek lazım ama dünyadaki tüm sitelerin yüzde 42si deyince, devletlerin sitelerinin güvenlik açıklarından etkilendiği düşünülünce, eğer birşeyler yanlışsa düzeltmek gerekir diye düşünüyorum. Bugün tüm PHP kurulumları 8 son sürüme güncellense, bugünü kurtarsak bile, 'düzen' aynı kaldıkça, bir sonraki büyük güvenlik açığında aynısı yaşanacak, gelecekte aynı durumun olmaması için adım atılmalı. Umarım PHP topluluğu gerekeni yapar. PHPnin saygınlığı en güzel böyle korunur diye düşünüyorum (uzaktan böyle görünüyor 🙂 ).
@nefrit Mame de 2-3 farklı rom set olmasının sebibi bumuymuş? Nasıl bir kafa var bu adamlarda, bari ortak rom kitaplığı yapılsa da oraya bakmaya akıl etse sistemleri cihaz BIOS klasörü gibi rom ortak kitaplıkları olsa, oradan baksalar ya. İlginç
"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.
@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