PHP2Shell Güvenlik Açığı Nedir, Siteniz Etkilendi mi?

Siteniz WordPress, WooCommerce, Joomla ya da Drupal ile çalışıyorsa altında PHP var. 21 Ekim 2026'da PHP ekibi, kimlik doğrulama gerektirmeden sunucuda kod çalıştırmaya izin veren iki kritik açık için acil güncelleme yayımladı. Güvenlik dünyası bu ikiliye PHP2Shell diyor. Kaygılı birkaç e-posta aldık, "bizim site etkilendi mi?" diye soranlar oldu. Olayı baştan sona, kaynaklarıyla anlatalım; yönettiğimiz sitelerde neyi kontrol ettiğimizi de yazalım.

Kısaca

• PHP2Shell, CVE-2026-109618 ve CVE-2026-109619 numaralı iki açıktır; ikisi de CVSS v4.0 ölçeğinde 9,2 puan aldı.
• Saldırgan giriş yapmadan, tek bir web isteğiyle sunucuda kod çalıştırabiliyor; uygulama kodunun çalışmasına bile gerek yok.
• Düzeltme PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde (21 Ekim 2026). PHP 8.1 ve öncesi resmî güncelleme almıyor.
• Açıkları Wiz Research, Calif ve OpenAI araştırmacıları yapay zekâ modellerinin yardımıyla buldu.
• Yönettiğimiz PHP tabanlı siteler güvende; 22 Ekim 2026'da sunucu tarafında kendimiz kontrol ettik.

PHP2Shell nedir?

PHP'nin çekirdeğinde, isteklerin işlendiği katmanda bulunan iki bellek güvenliği hatasıdır. PHP'nin 21 Ekim tarihli güvenlik duyurusu ilkini "bellek tükenmesiyle bozulma üzerinden uzaktan kod çalıştırma", ikincisini "eski genel durum üzerinden uzaktan kod çalıştırma" diye adlandırıyor.

Teknik dili bırakalım. PHP her isteğe belirli bir bellek ayırır. İstek verisi hazırlanırken bellek limiti dolarsa PHP işini yarıda keser ve geride yarım kurulmuş veri kalır; temizlik aşaması bu yarım veriyi sağlammış gibi kullanır. İkinci hatada ise bir isteğe ait bilgi, belleği boşaltıldıktan sonra da sistemde kalıyor. Aynı PHP işçisi sıradaki isteği aldığında bu bayat bilgiye dokunuyor ve saldırgan o boşluğu kullanabiliyor.

Etkilenen aralık geniş: PHP 5.4'ten 8.5'e kadar. PHP ekibine göre web isteğine yanıt veren her kurulum risk altında; PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil. En yüksek risk mod_php'de, çünkü orada gösterilen saldırı uygulama kodu hiç çalışmadan tetikleniyor.

Bu açık neden bu kadar tehlikeli?

Saldırganın şifreye, eklentiye ya da yönetici paneline ihtiyacı yok. Tek bir hazırlanmış istek, sunucuda web işçisinin yetkisiyle kod çalıştırmaya yetiyor.

Wiz Research, WordPress, Drupal ve Joomla'nın test günündeki en güncel sürümlerinde girişsiz uzaktan kod çalıştırmayı gösterdi. Ekibin yazısına göre ekrana yalnızca "Hello World" basan basit bir PHP uygulaması da etkilenen sürümdeyse açık veriyor. Yani sitenin ne kadar sade ya da güncel olduğu kurtarmıyor; belirleyici olan PHP'nin kendisi.

Bir de bellek sızıntısı tarafı var. Wiz'in aktardığına göre bu yol, PHP işçisinin belleğindeki şifreleri, oturum anahtarlarını, API anahtarlarını ve sertifikaları dışarı verebiliyor. Kod çalıştırma olmasa bile bu tek başına ciddi bir veri kaybı demek.

Ölçek de korkutucu. İnternetteki web sitelerinin büyük çoğunluğu PHP kullanıyor ve PHP; cPanel, Plesk gibi kontrol panellerinin içinde de geliyor. ABD siber güvenlik ajansı CISA, güncellenemeyen PHP sistemlerinin güncellenene kadar internetten çekilmesini önerdi. İngiltere'nin siber güvenlik merkezi NCSC de aynı yönde uyarı yaptı.

Sorun nasıl ortaya çıktı?

Planlandığı gibi değil. Açıklar önceden bulunup PHP ekibine bildirilmişti; kamuoyu açıklaması için 22 Ekim hedefleniyordu. Ama 20 Ekim sabahı Hacker News'te iki kritik PHP açığının açıklanmak üzere olduğunu söyleyen bir gönderi çıktı. Gönderi kaldırıldı, ekran görüntüleri yayıldı. Güvenlik firması watchTowr açıkların gerçek olduğunu doğruladı.

PHP ekibi aynı gün bir ön duyuru yayımlayıp güncellemeyi 21 Ekim 14.00 UTC'ye çekti. Yamalar o gün çıktı.

Saldırganlar beklemedi. Help Net Security'nin aktardığına göre Amazon'un tuzak sunucu ağı MadPot, açıklamadan dört gün önce, 17 Ekim'de bir istismar denemesi kaydetti. watchTowr da 21 Ekim'den itibaren kendi tuzak ağında gerçek saldırılar gördüğünü açıkladı. CISA ise 21 Ekim'deki uyarısında kendi tarafında istismar gözlemlemediğini yazdı. Kaynaklar arasındaki bu fark olağan; herkes kendi verisini raporluyor.

Açığı kim buldu, nasıl düzeltildi?

Bulanlar Wiz Research, Calif ve OpenAI'daki araştırmacılar. Üç ekip keşifte, koordinasyonda ve yamaların doğrulanmasında birlikte çalıştı, her biri kendi yazısını yayımladı.

Hikâyenin ilginç tarafı yöntem. Wiz, çalışmada kendi aracı Wiz Atlas ile Gemini 4 Argon ve GPT-5.6 Sol modellerini kullandığını yazıyor: açığı bulmak, istismarı farklı PHP sürümlerine uyarlamak ve yamaları doğrulamak için. Wiz'e göre altta yatan hatalar on yıllardır koddaydı. Ekip, insan araştırmacılar için bu zinciri kurmanın çok zor olacağını, yapay zekâ modellerinin bu engeli ciddi biçimde düşürdüğünü söylüyor.

Düzeltme için PHP'nin resmî yolu tek: güncellemek. Yamalı sürümler şunlar:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35 (bu dalın desteği 31 Aralık 2026'da bitiyor)

PHP 7.4, 8.0 ve 8.1 için yalnızca kaynak koduna küçük yamalar yayımlandı, hazır paket yok. Linux dağıtımları ve barındırma sağlayıcıları düzeltmeleri kendi derlemelerine bu yolla uyguluyor; bu yüzden bazı sunucularda sürüm numarası değişmeden yama gelebiliyor.

Güncelleme hemen yapılamıyorsa PHP ekibi geçici önlemler de önerdi: session.upload_progress.enabled ayarını kapatmak, memory_limit ve post_max_size değerlerini yeniden düzenlemek. Ekip bunların tam koruma olmadığını açıkça belirtiyor. Cloudflare da bilinen saldırı yollarına karşı ücretsiz planlar dahil bütün müşterilerine ilk WAF kurallarını açtı.

Sitenizin etkilenip etkilenmediğini nasıl anlarsınız?

İlk iş PHP sürümüne bakmak. WordPress'te Araçlar > Site Sağlığı > Bilgi > Sunucu bölümü sürümü gösterir; barındırma panelinizde de PHP ayarları sayfası vardır.

• Sürüm 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35 ve üstüyse yama yüklü.
• Sürüm bunların altındaysa sağlayıcınıza düzeltmeyi kendi derlemesine uygulayıp uygulamadığını sorun. Uyguladıysa tarihini isteyin.
• Sürüm 8.1 ya da daha eskiyse PHP projesi artık güncelleme yayımlamıyor; siteyi desteklenen bir sürüme taşımak gerekiyor. Eski eklenti ve temalar yüzünden bu iş test ister.
• Sitenizi kendi sunucunuzda çalıştırıyorsanız dağıtımınızın güvenlik paketini kurun ve bütün PHP işçilerini yeniden başlatın.

Wiz'in önerdiği izleme işaretleri de var: ardından bellek limiti hataları gelen olağandışı çok parçalı istekler, tekrarlayan HTTP 500 yanıtları, alışılmadık büyüklükte ya da bozuk PHPSESSID çerezleri. Günlüklerde bunlardan birini görürseniz sağlayıcınızla ya da bizimle iletişime geçin.

Yönettiğimiz sitelerin güvenlik durumu ne?

Güvende. Yalnızca sağlayıcı açıklamasına yaslanmak istemedik; 22 Ekim 2026'da sunucu tarafına bağlanıp iki şeyi kendimiz doğruladık.

Birincisi derleme tarihleri. Sunucuda kurulu PHP 7.4'ten 8.5'e kadar her sürüm 21 Ekim 2026 tarihinde yeniden derlenmiş. Altyapı sağlayıcımızın bize gönderdiği bilgilendirmede düzeltmeyi o gün bütün sunuculara uyguladıkları yazıyordu; tarih birebir tutuyor.

İkincisi, açığın bilinen saldırı yolunun geçtiği oturum yükleme ilerlemesi özelliği (session.upload_progress) PHP 8.1'den 8.5'e kadar bütün sürümlerde kapalı. PHP ekibinin geçici önlem olarak önerdiği ayar, bizim sunucularda zaten devre dışı.

Sağlayıcımızın bilgilendirmesi iki noktayı daha ekliyor. Açığı kendi canlı sunucularında test etmişler ve sunucu yazılımı istekleri saldırının beklediğinden farklı işlediği için tetikleyicinin devreye girmediğini görmüşler. Her site de kendi sınırlı yetkili hesabında çalışıyor; olası bir başarılı saldırı sunucunun geri kalanına ya da yan sitelere ulaşamıyor.

Yönettiğimiz PHP tabanlı sitelerin tamamı kontrol altında. Hepsi iki ayrı yerde gün aşırı yedekleniyor: barındırma tarafında ve kendi NAS (ağa bağlı depolama) cihazımızdaki RAID yapılı disklerde. Bir şey ters giderse siteyi yakın tarihli bir yedekten geri döndürebiliyoruz.

Yeni projelerde ilk önerimiz çoğu zaman Next.js oluyor. Maliyeti daha yüksek, ama daha hızlı çalışıyor ve SEO tarafında daha rahat ediyor. Bu onu hatasız yapmıyor; her teknolojide bir gün açık çıkabilir. PHP altyapılı siteler de bu olay yüzünden güvensiz sayılmaz. Güncel tutulan ve düzenli yedeklenen bir PHP sitesi güvenle çalışmaya devam eder.

Yapay zekâ bu sefer neden bizim tarafımızdaydı?

Çünkü on yılı aşkın süre fark edilmeyen hatayı yapay zekâ destekli araştırmalar buldu. Ajanslar, freelancer'lar, tasarımcılar ve videograferler olarak son iki yılda en çok konuştuğumuz korku yapay zekânın işimizi elimizden alması. O korku yersiz değil, biz de hissediyoruz.

Ama bu hafta internetin büyük bir kısmını açık bırakan hatayı kapatan zincirde de yapay zekâ vardı. Aynı araçlar saldırganların da elinde; Wiz'in yazısı istismarı kolaylaştıran şeyin de bu modeller olduğunu saklamıyor. Fark, onları kimin daha hızlı kullandığında. Biz de sunucu kontrollerini yapay zekâ destekli bir kod asistanıyla birkaç dakikada tamamladık; e-postayı okuduktan kısa süre sonra elimizde ölçülmüş bir sonuç vardı.

Sitenizin hangi PHP sürümünde çalıştığını bilmiyorsanız ya da sağlayıcınızdan net bir yanıt alamadıysanız bize yazın, birlikte bakalım. Güvenliği baştan düşünülmüş bir site için web tasarım hizmetimizi, benzer bir olayı nasıl anlattığımızı görmek için Yandex veri merkezi saldırısı yazımızı inceleyebilirsiniz.