PHP2Shell: İnternetin Altındaki Katman Kırıldığında Ne Oluyor?

PHP2Shell nedir? İki kritik PHP açığının teknik nedenlerini, yapay zekânın güvenlik araştırmalarındaki rolünü ve kurumlar için risklerini inceliyoruz.

İnternetin büyük bölümünü ayakta tutan teknolojilerin ne kadar güvenli olduğunu gerçekten biliyor muyuz?

21 Ekim 2026'da açıklanan iki kritik PHP güvenlik açığı bu soruyu yeniden gündeme taşıdı. PHP2Shell olarak adlandırılan CVE-2026-109618 ve CVE-2026-109619, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırılmasına olanak verebilen, CVSS 4.0 sisteminde 9,2 puanla değerlendirilen güvenlik açıkları.

Bu gelişme yalnızca bir yazılım güncellemesi meselesi değil. Bazı kamu kurumlarının web sitelerini önlem amacıyla erişime kapatması, büyük teknoloji şirketlerinin acil koruma mekanizmaları geliştirmesi ve güvenlik araştırmacılarının yapay zekâ kullanarak yıllardır gözden kaçan sorunları ortaya çıkarması, çok daha büyük bir dönüşüme işaret ediyor.

Benim ilgimi çeken ise olayın üç boyutu: Modern internetin ortak altyapı bağımlılıkları, yapay zekânın güvenlik araştırmalarını nasıl değiştirdiği ve kurumların kendi sistemlerini gerçekte ne kadar tanıdığı.

İnternetin görünmeyen bağımlılığı

PHP, yaklaşık otuz yıldır web teknolojilerinin temel bileşenlerinden biri.

WordPress, Drupal, Joomla ve sayısız kurumsal uygulama PHP kullanıyor. W3Techs verilerinde PHP, sunucu tarafı programlama dili bilinen web siteleri arasında yaklaşık %70 seviyesinde bir kullanım payına sahip.

Ancak burada önemli bir ayrım var.

PHP kullanan web sitelerinin çokluğu, bunların tamamının aynı ölçüde saldırıya açık olduğu anlamına gelmiyor. Güvenlik riski; kullanılan PHP sürümüne, işletim sistemine, web sunucusu mimarisine ve uygulanan korumalara bağlı.

Yine de ortak bağımlılığın boyutu dikkat çekici.

İnternette birbirinden tamamen bağımsız görünen binlerce uygulama, gerçekte aynı temel çalışma zamanı bileşenlerine dayanıyor.

Bu bileşenlerden birinde kritik bir sorun ortaya çıktığında etki, tek bir ürünü veya sektörü aşabiliyor.

Büyük saldırı yüzeyleri bazen çok sayıda farklı uygulamadan değil, hepsinin altında çalışan ortak teknolojiden kaynaklanıyor.

PHP2Shell teknik olarak neyi değiştirdi?

PHP2Shell'i alışılmış uygulama güvenliği açıklarından ayıran özellik, sorunun PHP'nin kendi çalışma mekanizmasında bulunması.

CVE-2026-109618, PHP'nin bellek tükenmesi ve istek temizleme işlemleri sırasında ortaya çıkabilen bellek bozulmasıyla ilişkili.

CVE-2026-109619 ise bir isteğe ait bellek durumunun sonraki işlemlerde hatalı biçimde yeniden kullanılabilmesinden kaynaklanıyor.

Her iki sorunun da temelinde bellek yönetimi bulunuyor.

Saldırgan, özel hazırlanmış HTTP istekleriyle PHP'nin hatalı bellek durumuna girmesini sağlayabiliyor. Uygun koşullar oluştuğunda bu durum bellek içeriğinin açığa çıkmasına veya PHP işleminin kontrolünün ele geçirilmesine kadar ilerleyebiliyor.

Burada dikkat edilmesi gereken nokta şu:

Bazı istismar senaryolarında saldırı, web uygulamasının kendi kodu çalışmaya başlamadan önce gerçekleşebiliyor.

Bu da uygulama seviyesindeki kimlik doğrulama mekanizmalarının veya güvenlik eklentilerinin tek başına yeterli olmayabileceği anlamına geliyor.

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed gibi farklı çalışma modellerinin değerlendirilmesi gerekiyor. PHP güvenlik ekibi, özellikle Apache mod_php mimarisinin daha yüksek risk taşıdığını belirtiyor.

Dolayısıyla sorun yalnızca WordPress güncellemekle veya bir güvenlik eklentisi kurmakla çözülemiyor.

Bir güvenlik açığı neden kamu hizmetlerini durdurabilir?

PHP2Shell'in açıklanmasının ardından Hollanda, Fransa ve Finlandiya'daki bazı kamu web hizmetlerinin tedbir amacıyla çevrimdışı bırakıldığı bildirildi.

Burada iki farklı durumu birbirinden ayırmak gerekiyor.

Bir sistemin güvenlik önlemi olarak kapatılması, mutlaka saldırıya uğradığı anlamına gelmez.

Hatta belirli koşullarda erişimi geçici olarak durdurmak, olası bir veri ihlalini önlemenin en doğru yöntemi olabilir.

Ancak bu kararın başka bir maliyeti bulunuyor: Hizmet sürekliliği.

Bir kamu kurumu web hizmetini kapattığında vatandaşların bilgiye erişimi ve bazı çevrimiçi işlemler etkilenebiliyor. Ticari kurumlarda ise müşteri işlemleri, gelir ve operasyonel süreçler kesintiye uğrayabiliyor.

Bu nedenle kritik açık yönetimi yalnızca bilgi güvenliği ekibinin vereceği teknik bir karar olmaktan çıkıyor.

Kurumlar aynı anda üç riski yönetmek zorunda kalıyor:

• Güvenlik açığının istismar edilmesi
• Sistemleri güncellerken hizmet kesintisi yaşanması
• Hiçbir şey yapmamanın doğuracağı olası veri ve operasyon kayıpları

Bu tablo, iş sürekliliği planları ile siber güvenlik süreçlerinin neden birlikte düşünülmesi gerektiğini gösteriyor.

Yapay zekâ artık güvenlik açığı buluyor

Olayın bence en dikkat çekici kısmı burada.

PHP2Shell'in keşfinde yapay zekâ destekli kod analizi ve güvenlik araştırma araçlarının önemli rol oynadığı açıklandı.

Wiz araştırmacıları, yapay zekâ destekli çalışmalarla PHP'nin bellek yönetimindeki sorunları tespit ettiklerini ve bunların gerçek uygulamalarda nasıl istismar edilebildiğini gösterdiklerini belirtiyor.

Bu önemli bir eşik.

Çünkü yapay zekâ artık yalnızca saldırı kayıtlarını özetleyen veya şüpheli faaliyetleri sınıflandıran yardımcı bir teknoloji değil.

Kaynak kodu inceleyebiliyor, hata örüntülerini araştırabiliyor, karmaşık bellek yönetimi problemlerini analiz etmeye yardımcı olabiliyor ve güvenlik araştırmacılarının daha önce çok zaman alan çalışmalarını hızlandırabiliyor.

Fakat bunun çift taraflı bir etkisi var.

Savunma ekipleri açıkları daha hızlı bulabilecek.

Aynı yeteneklerden yararlanan saldırganlar da uygun koşullarda istismar araştırmalarını hızlandırabilecek.

Bu nedenle önümüzdeki dönemin en önemli güvenlik göstergelerinden biri, yalnızca kaç güvenlik açığının bulunduğu değil, açığın öğrenilmesi ile kurumun kendisini koruyabilmesi arasında geçen süre olacak.

Bir başka ifadeyle, yapay zekâ güvenlik araştırmalarını hızlandırırken kurumların yama yönetimi süreçleri aynı hızda gelişmezse aradaki operasyonel açık büyüyebilir.

Asıl güvenlik açığı bazen envanterde

Bir kurumda kritik bir PHP açığı yayımlandığını düşünelim.

İlk sorumuz doğal olarak şu olacaktır:

Hangi sunucularımız etkileniyor?

Bu soruya birkaç dakika içinde güvenilir yanıt verebiliyor muyuz?

PHP yalnızca internete açık kurumsal web sitelerinde çalışmıyor.

Eski intranet uygulamalarında, üçüncü taraf ürünlerde, otomasyon araçlarında, konteyner imajlarında ve yıllardır güncellenmemiş yardımcı servislerde de bulunabiliyor.

Sunucu envanterinin güncel olması bile yeterli olmayabilir.

Çünkü sunucunun işletim sistemini bilmek, üzerinde çalışan PHP runtime sürümünü veya uygulamanın hangi bileşenleri kullandığını bilmek anlamına gelmiyor.

Örneğin Ubuntu üzerinde çalışan bir sunucuda işletim sistemi paket yöneticisinden güncellenmiş PHP ile uygulamanın kendi içinde barındırdığı PHP sürümü farklı olabilir.

Bu nedenle etkilenme analizi sunucu, uygulama ve bileşen düzeyinde yapılmalı.

ISO 27001 gibi standartlar kapsamında hazırlanan bilgi varlığı envanterleri de burada yalnızca denetimde gösterilecek belgeler olmaktan çıkıyor.

Güncel ve teknik olarak anlamlı bir envanter, olay müdahalesinin başlangıç noktası haline geliyor.

Bilmediğimiz bir bileşeni zamanında yamamak neredeyse imkânsız.

Patch uygulandıysa gerçekten güvende miyiz?

21 Ekim 2026 itibarıyla yayımlanan düzeltilmiş PHP sürümleri şöyle:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 ve daha eski sürümler PHP projesinin standart destek kapsamı dışında bulunuyor.

Ancak bu, eski sürüm numarası görülen her Linux sunucusunun otomatik olarak savunmasız olduğu anlamına gelmiyor.

Ubuntu gibi bazı dağıtımlar güvenlik düzeltmelerini kendi paketlerine geri taşıyabiliyor. Buna backport adı veriliyor.

Dolayısıyla yalnızca php -v çıktısına bakarak karar vermek doğru değil. Paket revizyonu ve dağıtımın güvenlik duyuruları kontrol edilmeli.

Güncelleme sonrasında servislerin yeniden başlatılması, uygulama testlerinin tamamlanması ve güvenlik taramalarının tekrarlanması da gerekiyor.

Ama benim için en önemli soru bunlardan sonra geliyor:

Sistem güncellenmeden önce istismar edilmiş olabilir mi?

Çünkü patch uygulamak mevcut güvenlik açığını giderir. Önceden gerçekleşmiş olabilecek bir saldırının izlerini temizlemez.

Bu nedenle kritik RCE açıklarında anormal HTTP istekleri, PHP veya web sunucusu hataları, beklenmeyen alt süreçler, değiştirilmiş dosyalar ve olağan dışı dış bağlantılar ayrıca incelenmeli.

WAF korumaları saldırı yüzeyini azaltabilir. EDR ürünleri şüpheli faaliyetlerin tespitinde yardımcı olabilir.

Ancak hiçbirinin tek başına bütün saldırı yollarını kapattığı varsayılmamalı.

Türkiye açısından nasıl okumalıyız?

Türkiye'deki kurumlar için PHP2Shell'in önemi yalnızca web sitelerinin güncelliğiyle sınırlı değil.

Özellikle uzun yıllardır çalışan kurumsal uygulamalar, dış kaynakla geliştirilen yazılımlar ve bakım sorumluluğu belirsiz sistemler önemli bir risk alanı oluşturuyor.

Bir kurumda ana web sitesi güncel olabilir. Ancak aynı kurumun eski anket uygulaması, bayi portalı, raporlama sistemi veya üçüncü taraf yönetim arayüzü farklı PHP sürümleriyle çalışıyor olabilir.

Üstelik bu uygulamalar çoğu zaman farklı ekiplerin sorumluluğunda bulunuyor.

Böyle bir durumda güvenlik açığının giderilmesi teknik kapasiteden önce koordinasyon problemine dönüşebiliyor.

Kim uygulamanın sahibi?

Kim güncelleme yapmaya yetkili?

Güncelleme mevcut uygulamayla uyumlu mu?

Test ortamı bulunuyor mu?

Sorumlu tedarikçi ne kadar hızlı yanıt verebiliyor?

Benzer durumlar yalnızca PHP için geçerli değil. Java, Apache, OpenSSL ve diğer yaygın altyapı bileşenlerinde de yaşanabiliyor.

Bu nedenle kurumların kritik güvenlik açıklarına hazırlığı, yalnızca güvenlik ürünlerine yapılan yatırımla ölçülmemeli.

Varlık görünürlüğü, sorumlulukların netliği, bağımlılık yönetimi ve test edilmiş müdahale süreçleri de en az güvenlik teknolojileri kadar önemli.

Güvenlik açıklarından daha hızlı hareket etmemiz gerekiyor

PHP2Shell bize yalnızca iki kritik güvenlik açığının nasıl kapatılacağını göstermiyor.

Modern internetin ortak yazılım bağımlılıkları üzerine kurulu olduğunu, bu bağımlılıkların büyük bir saldırı yüzeyi oluşturabildiğini ve yapay zekânın güvenlik araştırmalarının hızını değiştirmeye başladığını gösteriyor.

Bence burada asıl değişmesi gereken yaklaşım şu:

Güvenlik açıklarını yalnızca yayımlandıktan sonra müdahale edeceğimiz olaylar olarak görmemeliyiz.

Hangi sistemlerin hangi bileşenlere bağımlı olduğunu önceden bilmeli, kritik sistemlerin sahipliğini netleştirmeli, yama uygulama süreçlerini düzenli test etmeli ve olası bir istismarın izlerini araştırabilecek görünürlüğe sahip olmalıyız.

Yapay zekâ sayesinde daha fazla güvenlik açığını daha hızlı keşfetmeye başlıyoruz.

Bu iyi haber.

Ancak kurumların bu keşiflere yanıt verme kapasitesi aynı hızla gelişmiyorsa ortaya yeni bir dengesizlik çıkıyor.

Ve belki de PHP2Shell'in bize söylediği en önemli şey bu:

Gelecekte siber güvenliği yalnızca kaç açığı kapattığımız değil, bir açık ortaya çıktığında ne kadar hızlı anlayıp harekete geçebildiğimiz belirleyecek.