Web sitelerinin büyük bölümünün sunucu tarafında çalışan PHP programlama dilinde, saldırganların kimlik doğrulaması olmadan sunucuda kod çalıştırmasına imkân verebilen iki kritik açık kapatıldı. PHP geliştiricileri 21 Ekim 2026’da 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerini yayımlayarak “tüm PHP kullanıcılarına hemen güncelleme yapmalarını” önerdi. Türkiye’de T.C. Siber Güvenlik Başkanlığı (SGB) da aynı gün yayımladığı TR-26-1372 numaralı bildirimle kurum ve kuruluşları acil önlem almaya çağırdı.

Açıkları bulan Wiz Research ekibi bulguya “PHP2Shell” adını verdi. Açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarıyla izleniyor; Wiz’e göre önem derecesi CVSS ölçeğinde 9,2’ye ulaşıyor. Sorun tek bir eklentide ya da içerik yönetim sisteminde değil, PHP’nin kendi çekirdeğinde. Bu nedenle uygulama kodu temiz olan bir site de, güncellenmemiş bir PHP sürümü üzerinde çalışıyorsa risk altında olabiliyor.

Açık nerede, kimi etkiliyor?

PHP’nin güvenlik duyurusuna göre her iki açık da dilin bellek yönetimi ve hata işleme katmanında. İlki (CVE-2026-109618), bellek yetersizliği hatasının PHP’yi bir isteğin iç verileri yarı hazırken kesmesinden kaynaklanıyor; temizlik aşaması bu yarım veriyi geçerli sanabiliyor. İkincisi (CVE-2026-109619), bir isteğe ait iç durumun, belleği serbest bırakıldıktan sonra da kalabilmesi. Aynı işçi süreç bir sonraki isteği işlerken bu “bayat” veriyi kullanabiliyor.

Duyuruya göre web isteklerine yanıt veren tüm PHP kurulumları risk altında: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. PHP, en yüksek riski Apache mod_php yapılandırmasında görüyor; bu ortamda kimliği doğrulanmamış bir isteğin, uygulama kodu hiç çalışmadan saldırıyı tetikleyebildiği gösterilmiş. PHP Vakfı’nın aynı gün yayımladığı yazıya göre PHP-FPM üzerinde de uygulama düzeyindeki kod yollarıyla uzaktan kod çalıştırma doğrulandı.

Wiz, tek bir istismar betiğiyle WordPress, Drupal ve Joomla’nın güncel kurulumlarında kimlik doğrulamasız kod çalıştırmayı gösterdiğini açıkladı. Şirket ayrıca, kod çalıştırmaya gerek kalmadan PHP işçi sürecinin belleğinden parola, oturum anahtarı ve API anahtarı gibi verilerin okunabildiğini bildirdi. Wiz’e göre son on yılda yayımlanan her PHP sürümü bu açıklardan en az birinden etkileniyor; etkilenen kod yolları PHP 5.4’e kadar uzanıyor.

Yapay zekâ, açığı istismara çevirdi

Olayı farklı kılan, keşif biçimi. Wiz’in anlatımına göre kusurlu kod on yılı aşkın süredir PHP’nin içindeydi; ama onu çalışan bir saldırıya dönüştürmek, birden çok hatayı zincirlemeyi ve her hedefin bellek düzenine göre uyarlama yapmayı gerektiriyordu. Şirket bu çalışmada Wiz Atlas, Gemini 4 Argon ve GPT-5.6 Sol modellerini kullandığını, modellerin istismarı farklı uygulamalara “saatler içinde” uyarlamayı mümkün kıldığını yazdı. Wiz, açıkları 24 Ağustos’ta PHP güvenlik ekibine bildirdi; düzeltmeler 21 Ekim’de koordineli açıklamayla birlikte yayımlandı.

Bu, savunma tarafı için de iki yönlü bir uyarı. Aynı araçlar yıllardır gözden kaçan hataları bulup kapatmayı kolaylaştırıyor; ama “bu açık pratikte istismar edilemez” varsayımını da zayıflatıyor. Karmaşıklık artık tek başına bir güvenlik önlemi sayılamıyor.

Dünyada siteler kapatıldı

Güncellemenin ardından birçok ülkede kurumlar önlem amaçlı olarak sitelerini erişime kapattı. BBC’nin aktardığına göre Finlandiya hükümetin kamuya açık web hizmetlerini geçici olarak durdurdu, Hollanda’nın siber güvenlik ajansı kendi sitesini kapattı, Wikimedia Vakfı da bazı sistemlerini geçici olarak devre dışı bıraktı. AB’nin siber güvenlik birimi CERT-EU ve İngiltere’nin Ulusal Siber Güvenlik Merkezi (NCSC), hemen yama yapılamayan sistemlerin internetten ayrılmasını önerdi.

Açığa maruz kalan sistemlerin sayısına ilişkin tahminler geniş bir aralıkta. Cybersecurity Dive’ın derlediği verilere göre bir araştırmacı 1,3 milyonun üzerinde savunmasız site öngörürken Palo Alto Networks 22,6 milyondan fazla açık kurulum tahmin etti. Cisco ise internete açık kurulumların yaklaşık yarısının, düzeltme alamayacak kadar eski sürümlerde çalıştığını değerlendirdi. ABD’nin siber güvenlik ajansı CISA, 21 Ekim’deki uyarısında yayım anı itibarıyla istismar gözlemlemediğini bildirirken bazı araştırmacılar erken istismar raporlarına dikkat çekti.

Türkiye açısından: SGB’nin üç önlemi

SGB’nin TR-26-1372 bildirimi, başarılı bir istismarda sistemlerde yetkisiz kod çalıştırılabileceği, uygulama verilerinin gizliliği ve hizmet sürekliliğinin etkilenebileceği uyarısını yapıyor. Bildirim üç önlem sıralıyor: etkilenen sistemlerin belirlenip gecikmeden güvenli sürümlere yükseltilmesi, yönetim arayüzlerine ve kritik PHP servislerine dış erişimin güvenlik duvarı kurallarıyla yalnızca yetkili IP adreslerine sınırlandırılması ve yurt dışı erişim ihtiyacı olmayan sistemlerin ivedilikle uluslararası trafiğe kapatılması.

Türkiye’de belediye, okul, dernek, sendika ve küçük işletme sitelerinin önemli bölümü, PHP sürümünü kullanıcının değil barındırma firmasının belirlediği paylaşımlı sunucularda çalışıyor. Bu sitelerin sahiplerinin çoğu teknik ekip istihdam edemiyor; güncelleme takvimi de büyük ölçüde hizmet sağlayıcının önceliklerine bağlı. Desteklenmeyen PHP 8.1 ve öncesinde kalan uygulamalar için resmî sürüm yok. PHP ekibi yalnızca kaynaktan derleyenler için 7.4, 8.0 ve 8.1’e asgari yamalar sağladı; dağıtım paketleri ve uzun süreli destek sağlayıcıları ise düzeltmeleri önceden aldı. PHP 8.2’nin güvenlik desteği de 31 Aralık 2026’da sona eriyor.

Bir sitenin ele geçirilmesi yalnızca teknik bir arıza değil. Sunucuda müşteri, üye ya da başvuru verisi tutuluyorsa 6698 sayılı KVKK’nın 12. maddesi veri sorumlusuna, ihlali Kurul’a ve ilgili kişilere en kısa sürede bildirme yükümlülüğü getiriyor. Son haftalarda KVKK’nın duyurduğu e-ticaret ihlallerinin önemli kısmında da üçüncü taraf yazılım bileşenlerindeki açıklar öne çıkıyordu.

Görünmeyen altyapının yükü

PHP2Shell, internetin “ortak malı” gibi kullanılan açık kaynak altyapının kırılganlığını bir kez daha gösterdi. Dünyanın en büyük teknoloji şirketleri ve barındırma sektörü bu dilin üzerinde milyarlarca dolarlık iş yürütürken çekirdeğin bakımı görece küçük bir ekip ve bağışlarla ayakta duran bir vakfın omzunda. Benzer açıkların keşfi artık yapay zekâ modellerine erişimi olan büyük güvenlik şirketlerinin elinde hızlanıyor; yamaları uygulama yükü ise teknik kadrosu olmayan küçük kurumlara, gönüllülere ve sistem yöneticilerine kalıyor. Daha geniş bir perspektiften bakıldığında asıl soru, ortak dijital altyapının güvenliğinin kimin bütçesiyle ve kimin emeğiyle sağlanacağı.

Adı benzese de bu olay, dün haberleştirdiğimiz Plex Media Server’daki Plex2Shell zincirinden farklı bir açık. Resmî güncelleme kanalından dağıtılan yazılımların yarattığı riskler için Rank Math PRO tedarik zinciri haberimize de bakabilirsiniz.

Yöneticiler ne yapmalı?

  • Sürümü doğrulayın: Sunucuda php -v ile sürümü kontrol edin; dağıtım paketi kullanıyorsanız dağıtımın güvenlik bültenine bakın. Paylaşımlı barındırmada sürümü panelden ya da sağlayıcıdan yazılı olarak teyit edin.
  • Güncelleyin ve süreçleri yeniden başlatın: 8.5.12, 8.4.27, 8.3.36, 8.2.35 veya dağıtımınızın yamalı paketine geçin; PHP-FPM ve web sunucusu işçilerini yeniden başlatın.
  • Hemen güncelleyemiyorsanız: PHP’nin önerdiği geçici ayarlar (örneğin session.upload_progress.enabled=0, düşük post_max_size) yalnızca bilinen bazı yolları kapatıyor; tek tam çözüm güncelleme. SGB’nin önerdiği erişim kısıtlarını uygulayın.
  • İzleri arayın: Wiz, olağandışı çok parçalı isteklerin ardından gelen bellek sınırı hatalarına, tekrarlayan HTTP 500 yanıtlarına, beklenmedik büyüklükte PHPSESSID çerezlerine ve açıklanamayan işçi süreç yeniden başlamalarına dikkat edilmesini öneriyor.
  • Sırları yenileyin: Güncelleme öncesi saldırı şüphesi varsa veritabanı parolalarını, API anahtarlarını ve oturum gizlerini değiştirin.