Açıklıklar ve Tehditler
Kritik PHP hatalarını düzeltmek "Güncelle"ye tıklamak kadar basit değil. Riskinizi nasıl değerlendireceğiniz ve kendinizi nasıl koruyabileceğiniz burada.
Nate Nelson, Katkıda Bulunan Yazar
Yeni veriler, kuruluşların PHP2Shell için yama yapma hızının saldırganların istismar etme hızına yetişmediğini gösteriyor. Siber güvenlik uzmanlarına göre durum anlaşılabilir, çünkü bu durumda güncelleme özellikle karmaşık.
Veriler 21 Ekim’de damla damla gelmeye başladı ve dünyanın yeni PHP açıklarına ilk tepkisinin resmini çizdi. Resim iç açıcı değildi.
İyi konumlanmış bazı uzmanlar olağanüstü hacimde tehdit faaliyeti tespit etti. Cloudflare CEO’su Matthew Prince, açıkların Çarşamba günü kamuya açıklanmasından önceki 10 saatte şirketinin binlerce istismar girişimi gözlemlediğini belirtti. 21 Ekim akşamı X’te yazdığı paylaşımda, "Açıklamanın ardından 45 dakikada bu sayı on binlere, 2 saat içinde yüz binlere, şimdi ise milyonlara çıktı" dedi.
Ertesi gün Check Point Research, istismar girişimlerinin dünya genelinde kuruluşların yüzde 10’una ulaştığını iddia etti. Diğer taraftan, savunmasız kuruluşların küçük bir yüzdesi görünür şekilde yeni PHP sürümlerine güncelleme yaptı.
Shodan’da keşfedilebilir dağıtımları örnek alan Ox Security araştırmacıları, düzeltilmiş sürümler kullanıma sunulduktan 24 saat sonra örneklerin yüzde 99’dan fazlasının yeni yama sürümü duyurmadığını tespit etti. Flare araştırmacıları da bu bulguyu destekledi ve örneklerin yüzde 73’ünün PHP Vakfı’ndan artık güncelleme almayan dalları duyurduğunu kaydetti. Grubun bu rakamları nitelendirdiğini, temel internet taramalarının bazı önemli nüansları kaçırdığını belirttiğini de ekledi.
Bu arada Cisco Talos, açık kaynak istihbaratına dayanarak tüm PHP sistemlerinin yaklaşık yarısının yama almayacağını tahmin etti.
23 Ekim sabahı Doğu saatiyle Ox, Dark Reading’e 99%’luk oranının yüzde 97,5’e düştüğünü bildirdi. Flare ise Dark Reading’e, yukarı akış destekli dalları yansıtan kamu kayıtlarının yüzde 27’si içinde yaklaşık yüzde 5’inin güncellendiğini söyledi.
PHP2Shell ile mücadele çoğu zaman "Güncelle"ye tıklamak kadar basit değil, uygulayıcılar bunu kabul ediyor. Yine de çoğu kuruluşun hemen kendini korumak için atabileceği adımlar var; kuruluşun tüm sistem filosunda PHP dağıtımlarını titizlikle bulmak, uzlaşma belirtilerini araştırmak ve derhal yama yapılamayan sistemlere erişimi kısıtlamak ya da çevrimdışı almak gibi.
1. Adım: PHP’yi Her Yerde Bulmak
İlk bakışta PHP2Shell’e karşı korunmak basit görünüyor. Söz konusu açıklar CVE-2026-109618 ve CVE-2026-109619’u kapsayan yeni sürümlere güncelleme yapılabiliyor. Uygulamada ise PHP2Shell’e yaklaşım kuruluştan kuruluşa çok farklı görünüyor ve PHP’nin nasıl, nerede ve hangi şekillerde kullanıldığına bağlı olarak daha fazla ya da daha az çaba gerektiriyor.
Siber güvenlik uzmanlarının tamamının işaret ettiği ilk ortak adım, kuruluşların PHP çalıştıran tüm varlıklarını keşfetmesi ve envanterlemesi. Söylendiği kadar kolay değil. Siber Güvenlik ve Altyapı Güvenliği Ajansı CISA’nın 21 Ekim güvenlik uyarısında da belirtildiği gibi PHP sadece web sitelerinde çalışan bir teknoloji değil, "sık sık diğer yazılımların bir bileşeni ve yaygınlığı doğrudan gözlemlenemeyebilir."
Flare araştırmacıları saldırı yüzeyini incelerken bunu doğrudan gördü. "Araştırmada beni en çok etkileyen şey, PHP’yi geleneksel web barındırma dışında ne kadar çok bulduğumuz oldu" diyor Flare’de kıdemli siber suç araştırmacısı Adrian Cheek. "Depolama cihazlarında, fiziksel erişim kontrol sistemlerinde, kameralarda ve uzaktan erişim arayüzlerinde tespit ettik. Sadece ana web sitelerinize bakıyorsanız ya da dış değerlendirmeyi 80 ve 443 portlarıyla sınırlıyorsanız bunların bir kısmını kaçırırsınız."
Bu tür bir maruziyetleri olan kuruluşlar için devam ediyor, "Genellikle bir depolama aygıtına ya da fiziksel erişim kontrol ünitesine giriş yapıp PHP kurulumunu bağımsız olarak güncelleyemezsiniz. Güncellenmiş ürün yazılımını üreticinin sağlaması gerekir. Üretici ürünün desteğini durdurduysa kuruluşun yaması olmayabilir."
"Güncelle"ye Tıklamak Kadar Basit Değil
Kenar durumları bir kenara bırakırsak, bir kuruluşun tüm PHP dağıtımlarını bulup listelemeyi başardığını varsayalım. Buradan itibaren işler şaşırtıcı şekilde daha da karmaşıklaşıyor.
Kamu verileri, dışarıdaki PHP’nin büyük kısmının eski dallarda çalıştığını öne sürüyor. "PHP 5 veya PHP 7 etrafında kurulmuş bir uygulama çalıştırıyorsanız, mevcut bir PHP sürümüne geçmek uygulamanın bazı bölümlerinin yeniden yazılmasını, bağımlılıkların değiştirilmesini ve kırılabilecek her şeyin test edilmesini gerektirebilir. Özellikle uygulama operasyonel açıdan önemli bir şeyi destekliyorsa kuruluşların bunu hafife almasının iyi bir nedeni var" diye açıklıyor Cheek.
Bu durumlarda düzeltme, kuruluşlar bunu sürdürmeyi seçerse yavaş bir süreç olacak. Neyse ki ve kafa karıştırıcı şekilde, eski PHP sürümleri her zaman kurtarılamaz değil.
Kamu kayıtlarındaki en yaygın sürüm 7.4.3, Ubuntu 20.04 ile birlikte gelen sürüm. Cheek’in belirttiğine göre, "Linux dağıtımları sıklıkla daha eski bir PHP sürüm numarasını korurken güvenlik düzeltmelerini geriye taşır. Dolayısıyla eski bir sürüm numarası yazılımın yama almadığı anlamına gelmez." İşletim sistemlerinin yanı sıra uygulamalar da paket halinde gelen PHP için düzeltmeleri geriye taşıyabilir.
Böylece güncel olmayan PHP çalıştıran kuruluşlar çok farklı kategorilere ayrılıyor: Bazı kuruluşlar uygulamalarını ya da ürünlerini taşımak veya değiştirmek için ağır iş yükünü üstlenmek zorunda kalacak. Bu arada uzmanlar, savunmasız sistemlerin tamamen çevrimdışı alınmasını değerlendirmelerini söylüyor. Cheek, PHP yapılandırmasına ulaşılabiliyorsa CVE-2026-109619’u hafifletmek için bir uzman ipucu da sunuyor.
"Bildirimli saldırılar PHP oturum yükleme ilerlemesi üzerinden ilerliyor, bu özellik varsayılan olarak açık ve uygulamada session_start çağrısına ihtiyaç duymuyor. session.upload_progress.enabled seçeneğini devre dışı bırakıp PHP çalışanlarını yeniden başlatmak, PHP sürümü yükseltmesi gerektirmeden onaylanmış oturum yükleme ilerlemesi saldırı yollarını engelliyor" diye açıklıyor, bunun diğer PHP2Shell açığı CVE-2026-109618’i ele almadığını, dolayısıyla en fazla geçici bir önlem olduğunu vurgulayarak.
Bazı kuruluşlar satıcıları üzerinden geriye taşınmış düzeltmeleri kurma ayrıcalığına sahip olacak. 21 Ekim’de Ubuntu geliştiricisi Canonical, 14.04’ten itibaren tüm sürümler için PHP2Shell düzeltmelerini yayımladı. Bu rahatlamış taraflar bile daha fazla muhasebe çalışması yapmak zorunda kalacak, çünkü bir işletim sistemi ya da uygulama güncellemesi tam bir PHP sürüm yükseltmesini garanti etmiyor. Ubuntu güncellemelerinden yararlanılırsa, gelecekteki taramalar yazılımın görünürde PHP 7.4.3 çalıştığını göstermeye devam edebilir.
Ve Cheek hatırlatıyor: "Yeniden başlatma önemli. Düzeltilmiş bir PHP paketinin kurulması, çalışan işçi süreçlerine zaten yüklenmiş olan yorumlayıcının mutlaka değiştirilmesi anlamına gelmiyor."
Her PHP2Shell Vakası Farklı Olacak
Tüm teknik detayların ötesinde, kuruluşların PHP2Shell’e nasıl yanıt verebileceği büyük ölçüde büyüklüklerine bağlı.
Her acil siber güvenlik açığında olduğu gibi, küçük işletmeler farkındalık ve kendilerini temizleme için gerekli kaynaklar bakımından dezavantajla başlayabilir. Yine de PHP2Shell ile 1.000’den fazla kuruluşa 48 saat aralıksız çalışarak yardım ettikten sonra OX Security CEO’su Neatsun Ziv, küçük olmanın avantajlarını daha hızlı vurguluyor.
"Küçük kuruluşlarda istediğinizi yapabilirsiniz. Girip yamarsınız. Beş saat beklersiniz. Kimse bir şeyi bozduğunuz için şikâyet etmez" diyor.
Ama daha büyük kuruluşlar farklı, diyor. "Onların altın imajı var — güncelledikleri tek sunucu tabanı" diyor Ziv. "Her zaman aşağı akış modeli: yeni bir altın imajı dağıtıyorsunuz, bu altın imaj yeni yazılımla oluşturuluyor, bu yeni yazılım üretime gidiyor ve kimse üretimi değiştiremiyor. Bu, günümüz dağıtımlarında norm. Kimse sunuculara gidip gerçekten yama yapmıyor. Uzun vadede sürdürülemez hâle geliyor."
Ve büyük bir kuruluş içinde büyük güncellemelere farklı ekiplerden kaç kişinin dahil olması gerektiği; büyük kuruluşların kırılmaya tahammülü olmayan orantısız derecede önemli sistemler çalıştırması; ya da PHP’nin bir kuruluş içinde bile ne kadar yaygın ve çeşitli olabileceği gibi konular bir yana. Ziv’in belirttiğine göre, "Çalıştığımız kuruluşların çoğu PHP çalıştıran yüzlerce sunucu buldu."
Check Point baş güvenlik ve güven sorumlusu Alex Spokoiny, evin ötesinde kuruluşların tüm tedarikçilerinin PHP2Shell ile nasıl başa çıktıklarından da risk taşıdığını ekliyor.
"İlk adım, ilgili tedarikçilerle etkileşime geçmek ve nasıl yanıt verdiklerini anlamaktır. Etkileniyorlar mı? Hangi korumaları uygulamışlar? Düzeltmenin ne zaman tamamlanmasını bekliyorlar? Bu sorulara net ya da makul yanıtlar alamıyorsanız, bu bile risk değerlendirmenize dâhil etmeniz gereken bir şeydir ve alternatif seçenekleri değerlendirmeyi göz önünde bulundurmalısınız" diye tavsiyede bulunuyor.
Kuruluşlar ayrıca birbirleriyle iş birliği yaparak herkesin faydasına olabilir. "Teknik olarak mümkün olduğunda, üçüncü taraflarca işletilen uygulamalara kendi Web uygulama güvenlik duvarı korumalarını genişleterek sağlayabilirler, bu da sağlayıcının kalıcı bir düzeltmeye çalışırken maruziyeti azaltmaya yardımcı olur" diyor Spokoiny.
