PHP2Shell, Türkiye’de internete açık kurumsal uygulamaların güvenliği açısından acil bir güncelleme gündemi oluşturdu. Risk, yalnızca eski bir web sitesinin çalışmaya devam etmesiyle sınırlı değil. Aynı PHP altyapısı üzerindeki müşteri uygulamaları, üniversite hizmetleri, belediye portalları ve yönetim ekranları da etkilenebilir. İlk günlerde düzeltilmiş sürümlerin görünür hale gelmesi olumlu; ancak eski sürümlerin varlığı, müdahalenin henüz tüm ortamlara ulaşmadığını gösteriyor.
Gais Cyber Security olarak sızma testlerinde sıkça karşılaştığımız bir durum var: uygulama güncellenirken, onu çalıştıran PHP motoru yıllarca aynı kalabiliyor. PHP2Shell bu eksikliğin sonuçlarını görünür hale getiriyor. CMS, eklenti veya uygulama kodunu güncellemek, alttaki çalışma ortamı etkilenmeye devam ediyorsa yeterli olmuyor.
Risk uygulamanın altında başlıyor
CVE-2026-109618 ve CVE-2026-109619, PHP’nin bellek yönetimi ve istekler arasında taşınan iç durumuyla ilişkili iki kritik zafiyet. CVSS v4.0 puanları 9,2; uygun koşullarda kimlik doğrulaması olmadan, web isteğini işleyen sürecin yetkileriyle uzaktan kod çalıştırmaya yol açabiliyorlar. Başarılı bir saldırı, uygulama verilerinin ve sunucunun erişebildiği kimlik bilgilerinin tehlikeye girmesine, kalıcılık kurulmasına veya başka sistemlere erişim aranmasına zemin hazırlayabilir. [1, 2]
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed ile web isteği işleyen kurulumlar kapsamda. PHP ekibi, uygulama kodu henüz çalışmadan tetiklenebilen bir istismarın gösterildiği mod_php ortamlarını en yüksek riskli yapılandırma olarak öne çıkarıyor. Bu nedenle uygulamadaki oturum açma ekranına veya yetkilendirme kontrollerine güvenmek, çalışma ortamındaki açığı kapatmıyor. [1]
21 Ekim’de yayımlanan PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 sürümleri ilk iki zafiyetin düzeltmelerini içeriyor. Eski dallarda ise sağlayıcının güvenlik yamaları kontrol edilmeli; PHP 7.4, 8.0 ve 8.1 için hazırlanan asgari kaynak yamaları uzun vadeli destek yerine geçmiyor. Kalıcı hedef, desteklenen ve güncel bir PHP ortamı olmalı. [1, 2]
Türkiye için neden önemli
22 Ekim’de Türkiye’de PHP kullandığı görülen 9.710 tekil IP, riskin tek tek sitelerin ötesinde bir altyapı meselesi olduğunu gösteriyordu. 24 Ekim’de görünür toplam yaklaşık 9.500–9.600 tekil IP düzeyinde. Bu büyüklük, doğrulanmış zafiyetli sunucu sayısı olarak okunmamalı; yine de kurumların ve hizmet sağlayıcılarının önceliklendirmesi gereken geniş bir dışa açık alan bulunduğunu ortaya koyuyor.
Barındırma altyapıları ortak sorumluluk alanı
Türkiye’deki PHP görünürlüğünün önemli bölümü barındırma, veri merkezi, bulut ve internet servis sağlayıcılarının ağlarında yoğunlaşıyor. 22 Ekim’de bu iki grubun toplam payı yaklaşık %76’ydı. 24 Ekim dağılımında da ağırlık değişmiyor: barındırma ve ISS kategorileri birlikte yaklaşık %74’lük bir paya sahip. Kurumların kendi ekipleri kadar, hizmet aldıkları sağlayıcılarla kurdukları güncelleme koordinasyonu da belirleyici.
Barındırma ile ISS arasındaki pay değişimi, sorumluluğun başka bir sektöre geçtiği anlamına gelmiyor. Aynı işletmeci hem bağlantı hem barındırma hizmeti verebiliyor. Yurt dışında kayıtlı ağların payı %17,8’den %9,8’e gerilerken bireysel abonelerin payı %3,3’ten %4,9’a çıkıyor. Bu hareketler tek başına hangi grubun daha hızlı yama yaptığını göstermiyor; riskin farklı ağ türlerinde devam ettiğini gösteriyor.
Üniversitelerin tekil IP payı iki tarihte de yaklaşık %2,2–2,3; belediye ve meslek kuruluşlarının payı ise %0,2 düzeyinde. Küçük paylar düşük kurumsal etki anlamına gelmiyor. Öğrenci işleri, personel sistemleri veya vatandaş hizmetleri gibi uygulamalarda tek bir sunucunun etkilenmesi bile çok sayıda kullanıcıyı ilgilendirebilir. Ayrıca barındırma firmalarının ağlarındaki kurumsal siteler, bu kurumların kendi ağ kategorilerinde görünmeyebilir.
24 Ekim itibarıyla 50’ye yakın üniversiteyle ilişkilendirilen PHP kayıtları ve .edu.tr, .bel.tr, .gov.tr, .k12.tr uzantılarında 198 kayıtlı alan adı görülüyor. Alan adlarının 88’i .edu.tr, 82’si .bel.tr, 16’sı .gov.tr ve 12’si .k12.tr uzantılı. Bu kayıtlar her bir sitenin zafiyetli olduğunu kanıtlamasa da eğitim ve yerel yönetim hizmetlerinin güncelleme gündeminde öncelik taşıdığını gösteriyor.
Coğrafi görünürlükte İstanbul öne çıkıyor. Ancak verilerin barındırma altyapısının yerini yansıtabilmesi nedeniyle riskin yalnızca belirli şehirlerdeki kurumlarla sınırlı olduğu düşünülmemeli. İstanbul’da barındırılan bir uygulama, Türkiye’nin başka bir şehrindeki kurumun kritik hizmetini sunuyor olabilir.
İlk iki günde iyileşme işaretleri
Yamaların yayımlanmasını izleyen dönemde Türkiye tablosu değişmeye başladı. Türkiye’de PHP görülen tekil IP toplamı, 22 Ekim’deki 9.710’dan 24 Ekim’de yaklaşık 9.500–9.600 aralığına geriliyor; bu, yaklaşık %1–2’lik bir azalmaya karşılık geliyor. Aynı zamanda düzeltilmiş sürüm kayıtları belirginleşiyor. Düzeltilmiş sürümlerin görünürlüğü müdahalenin başladığına işaret ediyor. Toplamdaki azalma ise hizmetlerin geçici kapatılması, dış erişimin sınırlandırılması veya kayıtların yenilenmesiyle ilişkili olabilir; PHP güncellendiğinde de görünür kalabileceği için bu azalmayı doğrudan yamalama başarısı saymıyoruz.
PHP 8.3.36’nın 1.234 kayıtla öne çıkması, bu dalda güncellemenin görünür hale geldiğini gösteriyor. Dört düzeltilmiş sürüm için toplam 1.394 kayıt bulunması da olumlu bir işaret. Ancak bunlar aynı sistemlerin iki tarih arasındaki geçişini izleyen sayılar olmadığından, Türkiye için kesin bir yamalama oranı veya tamamlanma hızı vermek mümkün değil. Buradaki değerlendirme, ilk günlerde müdahalenin başladığı; buna karşılık güvenli sürüme geçişin tamamlandığının henüz söylenemeyeceği yönünde.
Eski sürümler kurumsal riski sürdürüyor
Özellikle PHP 5.x ve 7.x gibi eski dalların görünür olmaya devam etmesi, acil yamanın yanında bir yenileme ihtiyacına işaret ediyor. Destek dışı sürümlerde beklemek, yalnızca PHP2Shell’i değil, yıllar içinde biriken başka güvenlik açıklarını da taşımak anlamına geliyor. Uygulama uyumluluğu nedeniyle yükseltilemeyen sistemler için dış erişimin daraltılması ve geçiş planının somut bir takvime bağlanması gerekiyor.
İstismar gündemi güncellemeden önce başladı
AWS, 21 Ekim tarihli açıklamasında MadPot sensörlerinde 17 Ekim’e uzanan bir istismar girişimi tespit ettiğini ve duyuru çevresinde başka girişimler de gördüğünü bildirdi. Huntress ise 21 Ekim’deki güncellemelerinde kendi müşteri tabanında istismar gözlemlemediğini açıkladı. Bu açıklamalar farklı zaman ve görünürlük alanlarını kapsıyor; bir ortamda olay görülmemesi, diğer ortamlarda girişim olmadığı anlamına gelmiyor. [3, 4]
Kurumlar açısından esas sonuç şu: riskin başlangıcı yamanın yayımlandığı gün değil. Güncelleme zafiyeti kapatsa da daha önce bırakılmış bir web shell’i, çalınmış kimlik bilgisini veya kurulmuş kalıcılığı ortadan kaldırmaz. Bu nedenle yama çalışmasına geçmişe dönük ihlal incelemesi eşlik etmeli. İnceleme en az bilinen ilk girişim tarihi olan 17 Ekim’i kapsamalı, eldeki bulgulara göre daha geriye genişletilmelidir. [3]
Kurumların şimdi yapması gerekenler
İlk adım, internete açık PHP ortamlarını eksiksiz belirlemek. Web siteleriyle birlikte kontrol panelleri, webmail, yönetim arayüzleri, konteynerler ve PHP’yi içinde taşıyan üçüncü taraf ürünler de bu kapsama alınmalı. Barındırma hizmeti alan kurumlar, sağlayıcılarından kullanılan PHP dalını, düzeltmenin kurulduğunu ve tüm ilgili süreçlerin yeniden başlatıldığını teyit etmelerini istemeli. [2, 4]
Güncelleme, paket kurulunca tamamlanmış sayılmamalı. Tüm PHP worker süreçleri, kullanılan mimariye göre web sunucuları ve konteynerler yeniden başlatılmalı; web isteklerinin gerçekten düzeltilmiş kodla işlendiği doğrulanmalı. Bir sunucudaki komut satırı PHP sürümü ile uygulamayı çalıştıran PHP ortamı farklı olabilir. Dağıtımın sürüm numarasını koruyarak eklediği yamalarda da paket sağlayıcısının güvenlik duyurusu esas alınmalı.
Hemen güncellenemeyen sistemlerde dış erişim sınırlandırılmalı; gerekirse hizmet geçici olarak dış ağa kapatılmalı. Resmî geçici önlemler arasında session.upload_progress.enabled=0 ve PHP 8.5 için fatal_error_backtraces=0 yer alıyor. Bunlar belirli saldırı yollarını sınırlar ve ilk iki CVE için yamanın yerini tutmaz. Bellek sınırını kaldırma gibi ayarlar ise kaynak tüketimi etkileri nedeniyle resmî yönergedeki tamamlayıcı kontrollerle birlikte değerlendirilmelidir. [1, 2]
Apache mod_php kullanan ortamlarda PHP-FPM’e geçiş de planlanabilir. Bu, süreç ve yetki ayrımını güçlendirmek için fırsattır; ancak PHP-FPM de etkilendiğinden güncelleme zorunluluğu sürer. WAF ve erişim kısıtlamaları da yama süresince ek koruma sağlayabilir, kalıcı çözüm yerine geçmez.
Güvenlik ekipleri web dizinlerindeki beklenmeyen dosyaları, PHP veya web sunucusundan başlatılan olağandışı süreçleri, yeni zamanlanmış görevleri ve şüpheli giden bağlantıları incelemeli. İnternetten indirilen “PoC” araçlarının çıktıları ise tek başına ihlal veya güvenlik kanıtı sayılmamalı; kaynağı ve davranışı doğrulanmamış kodlar üretimde çalıştırılmamalıdır. [4]
Gündem yalnızca 21 Ekim yamalarıyla da kapanmıyor. PHP’nin 23 Ekim duyurusu, alışılmadık oturum yapılandırmalarını etkileyen CVE-2026-115560 için ayrı bir uyarı içeriyor. Olağan sürüm döngüsünde ele alınacak bu vektör için session.upload_progress.enabled=0 öneriliyor. Kurumlar ilk iki açığın yamalarını uygularken sonraki resmî duyuruları da takip etmeli. [1, 2]
Türkiye için öncelik kalıcı iyileştirme
İlk günlerde güvenli sürümlerin görünür hale gelmesi olumlu. Buna rağmen eski PHP ortamlarının sürmesi ve kurumsal hizmetlerin ortak barındırma altyapılarına bağımlılığı, çalışmanın birkaç acil güncellemeyle bitmeyeceğini gösteriyor. PHP2Shell’e verilecek güçlü yanıt; güncel çalışma ortamı, sağlayıcılarla açık sorumluluk paylaşımı ve geçmiş ihlal incelemesinin birlikte yürütülmesi. Bu yaklaşım, bugünkü açığı kapatırken bir sonraki kritik duyuruya hazırlığı da güçlendirecektir.
Kaynaklar
[1] PHP güvenlik duyuruları, 21 ve 23 Ekim 2026 - https://www.php.net/
[2] CERT-EU 2026-018, 23 Ekim güncellemesi - https://cert.europa.eu/publications/security-advisories/2026-018
[3] AWS Security Blog, 21 Ekim 2026 - https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
[4] Huntress, 21 Ekim güncellemeleri - https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
Türkiye görünürlüğü ve grafikler: Shodan, 22 ve 24 Ekim 2026. Sayılar dışa açık hizmet kayıtlarını yansıtır; doğrulanmış ihlal sayısı değildir.
