Avrupa'da devlet kurumları, hastaneler ve üniversiteler, iki kritik PHP güvenlik açığı nedeniyle web sitelerini bilerek kapattı. Bu tercih olağan değil. Bir kurumun kendi hizmetini kendi eliyle durdurması, risk hesabının ne kadar ağır olduğunu gösteriyor. Daha büyük soru ise şu: Web'in büyük kısmını çalıştıran bir dilde yama neden bu kadar geç geldi?

Ne oldu?

Çarşamba günü Avrupa'nın farklı ülkelerinde kamu, sağlık ve eğitim kurumlarına ait siteler erişime kapandı. Operatörler bu siteleri kendileri çevrimdışı aldı. Yama dağıtılırken birkaç saatlik kesintiyi, açık bir sistemle yayında kalmaktan daha güvenli buldular. Kapatmalar, açıklara dair resmi bir uyarının ardından geldi.

Kamu kurumları neden kesintiyi açıkta kalmaya tercih etti?

Kurumsal güvenlikte genel kural basittir: Yayında kalmak varsayılan seçenektir, kapatmak son çaredir. Bu kuralın tersine çevrilmesi için üç koşulun aynı anda oluşması gerekir. Açık uzaktan ve kolay istismar edilebilir olmalı. Saldırganların harekete geçtiğine dair işaret bulunmalı. Bir de korunan veri hassas olmalı.

Hastane ve devlet sitelerinde üçüncü koşul zaten hep vardır. Randevu sistemleri, vatandaş başvuruları, öğrenci kayıtları çoğu zaman aynı sunucuda ya da aynı ağda durur. Bir web sitesinin birkaç saat kapalı kalması can sıkıcıdır, ama geri döndürülebilir. Sızdırılmış hasta verisi ya da fidye yazılımına kilitlenmiş bir hastane ağı geri döndürülemez. Kurumların hesabı bu asimetriye dayanıyor.

Buna bir de kamu altyapısının gerçeği ekleniyor. Pek çok kurum sitesi eski PHP sürümleriyle, dış yükleniciler tarafından kurulmuş ve sonra kendi haline bırakılmış sistemlerle çalışıyor. Bu tür ortamlarda "hemen yamala" bir seçenek olmayabilir. Hangi sunucuda hangi sürümün çalıştığını bilmeyen bir BT ekibi için en hızlı ve en güvenilir önlem fişi çekmektir. Kapatma kararı aslında bir envanter eksikliğinin de itirafı.

Yama süreci neden bu kadar uzadı?

Açığın 2024'te tespit edildiği ve aylarca kapatılamadığı bilgisi, olayı tekil bir güvenlik vakasından çıkarıp bir yönetişim sorununa dönüştürüyor. PHP, büyük bir şirketin ürünü değil. Geliştirmesi, kâr amacı gütmeyen PHP Foundation ve gönüllü katkıcılar üzerinden yürüyor. Vakıf, PHP'nin uzun yıllar birkaç kişinin omzunda kalmasına tepki olarak kuruldu. Ama kaynakları, bu dile dayanan ekonominin büyüklüğüyle kıyaslanamaz.

Bu tablo yeni değil. OpenSSL'deki Heartbleed, Log4j'deki Log4Shell ve xz araçlarına sızdırılan arka kapı aynı dersi verdi: Kritik altyapı, az sayıda ve çoğu zaman yetersiz finanse edilen bakımcıya bağlı. Fark şu ki PHP bir kütüphane değil, bir çalışma ortamı. Açığın düzeltmesi tek bir pakette bitmiyor. Dağıtım paketleyicilerine, barındırma firmalarına, WordPress gibi platformlara ve en sonunda tek tek sunucu yöneticilerine kadar uzanan bir zincirden geçmesi gerekiyor. Zincirin her halkası gecikme ekliyor.

Kime nasıl yansır?

TarafKısa vadeli etkiAsıl risk
Kamu kurumlarıSaatlik kesinti, itibar kaybıGüncellenmeyen eski sürümler
Barındırma firmalarıToplu yükseltme baskısıMüşteri sitelerinin bozulması
Küçük işletmelerSessizce açıkta kalmaKimsenin uyarmaması
PHP ekosistemiGüven sorgulamasıFinansman ve hız tartışması

En savunmasız grup, haberi hiç duymayacak olanlar. Büyük kurumlar en azından kapatma kararı verebildi. Paylaşımlı hostingte eski bir PHP sürümüyle çalışan küçük bir e-ticaret sitesinin böyle bir refleksi yok. Desteği biten sürümlerin hâlâ yaygın kullanıldığı biliniyor. Resmi destek takvimi dışında kalan sürümler için yama çoğu zaman hiç gelmiyor.

Türkiye açısından da tablo farklı değil. Belediyeler, üniversiteler ve KOBİ siteleri arasında PHP tabanlı sistemler yaygın. Bu olay, "bizde de olur mu?" sorusundan çok "hangi sunucumuzda hangi sürüm çalışıyor?" sorusunu sormak için bir uyarı.

Sırada ne var?

İzlenecek ilk şey, açıkların aktif olarak istismar edilip edilmediği. Kapatmalar önleyici ise kesinti kısa sürer. Saldırı izleri ortaya çıkarsa veri ihlali bildirimleri ve soruşturmalar gelir. İkincisi, AB'nin Siber Dayanıklılık Yasası (Cyber Resilience Act) bağlamında açık kaynak bakımcılarına yönelik sorumluluk ve finansman tartışmasının bu olayla hız kazanması olası. Üçüncüsü, kamu kurumlarının yazılım envanteri ve sürüm yönetimi için zorunlu standartlara yönelip yönelmeyeceği.

Kapatma kararı, açık karşısında doğru ama gecikmiş bir refleksti. Asıl başarısızlık o çarşamba günü yaşanmadı. Kritik bir açığın aylarca kapanmadan beklemesine izin veren finansman ve koordinasyon modelinde yaşandı. Bu model değişmedikçe, bir sonraki açıkta da kurumların elindeki en etkili araç yine fişi çekmek olacak.