
PHP2Shell Güvenlik Açığı: FBI'dan 'Sitenizi Kapatın' Uyarısı
21 Ekim 2026'da FBI Siber Bölümü kurumlara açık bir çağrı yaptı: hemen güncelleyemiyorsanız sisteminizi çevrimdışı alın. Uyarının hedefi PHP'deki PHP2Shell güvenlik açığıydı. W3Techs verisine göre sunucu tarafı dili belirlenebilen sitelerin yaklaşık yüzde 70'inin kullandığı bu dilde iki kritik açık, 9.2 CVSS skoruyla kimlik doğrulaması olmadan uzaktan kod çalıştırmaya imkan veriyor. Bu yazıda açığın ne olduğu, saldırının nasıl işlediği, hangi sürümlerin güvende olduğu ve site yöneticilerinin atması gereken somut adımlar ele alınıyor.
PHP2Shell Güvenlik Açığı Nedir?
PHP2Shell, PHP çekirdeğinde bulunan iki ayrı açığın ortak adı: CVE-2026-109618 ve CVE-2026-109619. Her iki açık da kimlik doğrulaması olmadan uzaktan kod çalıştırmaya imkan veriyor. Huntress'in aktardığına göre CVE-2026-109619 ayrıca işçi sürecinin belleğindeki verilerin sızdırılmasına da yol açabiliyor. Açık, üzerinde çalışan uygulamadan bağımsız olarak doğrudan PHP'nin kendisinde bulunuyor.
Sorunun tehlikeli yanı tam da burada. Açık WordPress'in bir eklentisinde ya da sitenin kendi kodunda değil, o kodu çalıştıran motorda. Expel'in aktardığına göre PHP, bazı istismar yollarının öngörülebilir bir log kaydı bırakmayabileceği uyarısını yaptı; yani boş bir log, sunucunun güvende olduğunu kanıtlamıyor. Bir kurum kendi kodunu titizlikle güvene almış olsa bile, altındaki PHP sürümü üzerinden açığa maruz kalabilir.

İki açık da PHP güvenlik ekibi tarafından CVSS v4.0 ölçeğinde 9.2 puanla, yani kritik seviyede derecelendirildi. Help Net Security'nin aktardığına göre en büyük tehlike Apache mod_php kullanan kurulumlarda. Çalışan bir istismar, kimlik doğrulamasız tek bir istekle, uygulama kodu tek satır çalışmadan önce saldırıyı tetikleyebiliyor.
FBI Ve NSA Neden Siteleri Kapatın Dedi?
x.com/FBICyberDiv/status/2112921648252719420
Daha da keskin olan talimat ise güncelleme yapamayanlar içindi. Digit'in aktardığı ifadeyle FBI, hemen güncellenemeyen sistemlerin tamamen giderilene kadar çevrimdışı alınmasını önerdi. Bir güvenlik açığı için bir devlet kurumunun "siteyi kapatın" demesi, sorunun ciddiyetini tek başına özetliyor.

Uyarı tek bir kurumla sınırlı kalmadı. Defense One'ın haberine göre NSA, FBI ve CISA kuruluşları birlikte uyardı; W3Techs verisine dayanarak sunucu tarafı dili belirlenebilen sitelerin kabaca yüzde 70'inin PHP kullandığını hatırlattı. PHP, WordPress, Drupal ve Joomla gibi platformların temelinde yer aldığı için etki alanı çok geniş.
Türkiye de hızla harekete geçti. Türkiye Gazetesi'nin aktardığına göre Cumhurbaşkanlığı Siber Güvenlik Başkanlığı, kamu kurumları başta olmak üzere ülke genelinde güvenlik taramaları başlattı ve ilgili kurumlara acil tedbir bildirimleri gönderdi. Açığın ağırlığını PHP Vakfı'nın kendi güvenlik mühendisi de teyit etti. The Journal'ın aktardığına göre Volker Dusch, Wall Street Journal'a yaptığı açıklamada PHP2Shell'i PHP'nin on yılı aşkın sürede karşılaştığı en ciddi sorun olarak niteledi ve 2014'teki Heartbleed açığına benzetti.
Vakfın kendi mühendisinden gelen bu değerlendirme, panik havasının neden bu kadar hızlı yayıldığını açıklıyor. Habertürk'ün Bloomberg HT'ye dayanarak aktardığına göre açığın kaynağı, PHP'nin bilgisayar belleğini yönetme biçiminden doğan bir hata grubu.

Saldırı Teknik Olarak Nasıl Gerçekleşiyor?
Açığın kalbinde PHP'nin bellek sınırına ulaştığında yaptığı iş var. PHP güvenlik ekibinden Alexandre Daubois'nın analizine göre bellek sınırı aşıldığında PHP'nin bellek ayırıcısı, belleği isteyen C fonksiyonunu yarıda bırakıp doğrudan istek işleyicisine atlıyordu. Sorun şu: o fonksiyon, arkasındaki yapıyı doldurmadan bir işaretçiyi yayınlamış olabiliyordu. mod_php ise istek başlangıcı bitse de bitmese de kapanış rutinini çağırdığı için, kimsenin tamamlamadığı bir yapı dolaşılıyordu.
Saldırganın tek ihtiyacı, ayırıcının tam olarak ne zaman başarısız olacağını belirlemek. Aynı analize göre multipart form ayrıştırma bunun için birkaç yol sunuyor. Beklenen uzunluğu bildirilmeyen bir gövde ilk boyut kontrolünü geçebiliyor. Bir form parçası, ağda kapladığından çok daha fazla bellek tüketen sayısız başlık taşıyabiliyor. Boş dosya alanları ise dosya sayısı sınırını atlayıp yine de üstveri dizileri oluşturuyor. Bunlar, ayırıcıyı istenen anda tökezletmenin yolları.

İkinci açık ise oturum (session) tarafında. Upwind'in incelemesine göre hata, multipart yükleme ilerlemesini izleyen oturum işlevinde yaşanıyor. PHP bazı bellek işaretçilerini kalıcı yapılarda saklıyor; ikinci bir istek oturumu yeniden okutunca bu yapı yok ediliyor ve geride bayat bir işaretçi kalıyor. Sonraki istek bu işaretçiye güvendiğinde ortaya use-after-free türü bir hata, dolayısıyla kod çalıştırma ya da bellek sızıntısı çıkıyor.
Bellek sızıntısı yolu ayrıca başlı başına bir risk. Huntress'in aktardığı Wiz bulgularına göre ayrı bir bellek ifşası yolu parola, token, API anahtarı ve sertifikaları açığa çıkarabiliyor. Yani saldırgan kod çalıştıramasa bile, sunucunun belleğinden sızan verilerle ciddi zarar verebiliyor. Daubois'ya göre düzeltme 390 dosyaya dokunuyor; bu da sorunun PHP'nin ne kadar derinine işlediğini gösteriyor.
Yukarıda saldırının yalnızca mantığı anlatıldı; çalışan istismar kodu veya adım adım saldırı tarifi bilinçli olarak verilmedi. Amaç, yöneticilerin riski doğru değerlendirmesi.
Açık Nasıl Sızdı, Yapay Zeka Ne Rol Oynadı?
Olayın en dikkat çekici yanı, açığın nasıl bulunduğu. Precursor Security'nin aktardığına göre güvenlik ekibi Calif, açığı OpenAI'nin "Patch the Planet" girişimi kapsamında GPT-5.6 Sol modeliyle tespit etti; Wiz ise iki açığı bağımsız olarak keşfedip bildirdi. PHP Vakfı'nın on yılı aşkın sürenin en ciddisi saydığı bir açığın yapay zeka modellerinin yardımıyla bulunması, savunma tarafı kadar saldırı tarafı için de yeni bir dönemin işareti olarak okunuyor.
Saldırı denemeleri ise duyurudan önce başlamıştı. Help Net Security'nin aynı haberine göre Amazon'un MadPot honeypot ağı, kamuya açık duyurudan dört gün önce, 17 Ekim'de bir PHP2Shell istismar denemesi kaydetti. Amazon denemenin arkasında bir tehdit aktörü olduğunu düşünüyor, ancak saldırganın ayrıntılara ambargo sürerken nasıl ulaştığı henüz bilinmiyor.
Sürecin kamuya sızması da planlı olmadı. The Hacker News'in haberine göre 20 Ekim'de Hacker News'te iki PHP açığının 22 Ekim'de duyurulacağını iddia eden bir gönderi paylaşıldı ve PHP yamayı bir gün öne çekti. Huntress'e göre gönderi kaldırıldı, ancak ekran görüntüleri o sırada sosyal medyada çoktan yayılmıştı. Sızıntının "CVSS 10.0" iddiası ise PHP'nin resmi 9.2 puanıyla örtüşmüyordu.

Olayın kronolojisi, bir açığın nasıl kontrolsüz biçimde kamuya düştüğünü net gösteriyor. Tablonun kaynakları Daubois'nın zaman çizelgesi, Help Net Security ve Huntress:
Tarih (2026) | Olay |
|---|---|
27 Ağustos | Açık, güvenlik danışmanlığı olarak açılır ve araştırmacılara atfedilir |
25 Eylül | Düzeltme için kod değişikliği talebi (PR) açılır |
17 Ekim | Amazon MadPot ağı ilk istismar denemesini kaydeder |
20 Ekim | Hacker News'teki sızıntı gönderisi kaldırılır ama ekran görüntüleri yayılır, PHP acil yama duyurusu yapar |
21 Ekim | PHP resmi duyuruyu yapar ve yamalı sürümleri yayınlar |
Bu tablo, yapay zeka yardımıyla bulunan bir açığın koordineli ifşa süreci tamamlanmadan nasıl sızabildiğini özetliyor.
Hangi PHP Sürümleri Güvende?
Korunmanın ilk şartı, güvenli sürümü bilmek. Help Net Security'nin haberine göre PHP ekibi 21 Ekim 2026'da dört düzeltme sürümü yayınladı: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Her daldaki bu sürümlerin altındaki tüm sürümler savunmasız kabul ediliyor. Tablodaki son savunmasız sürümler ve destek tarihleri Brandefense'in php.net'e dayanan derlemesinden alındı.
PHP Dalı | Savunmasız Son Sürüm | Güvenli Sürüm | Destek Durumu |
|---|---|---|---|
8.5 | 8.5.11 | 8.5.12 | 31 Aralık 2027'ye kadar aktif |
8.4 | 8.4.26 | 8.4.27 | 31 Aralık 2026'ya kadar aktif |
8.3 | 8.3.35 | 8.3.36 | 31 Aralık 2027'ye kadar güvenlik |
8.2 | 8.2.34 | 8.2.35 | 31 Aralık 2026'ya kadar güvenlik |
Asıl risk ise desteği bitmiş sürümlerde. Mynet'in aktardığına göre PHP 8.1 ve daha eski sürümler artık PHP projesinden düzenli güvenlik güncellemesi almıyor. Bu da internetin geniş bir bölümünü kalıcı risk altında bırakıyor. CybelAngel'ın taramasına göre internete açık 2,24 milyon PHP sunucusunun yüzde 59'u, resmi düzeltme sürümü gelmeyecek dallarda çalışıyor. Help Net Security'nin aktardığına göre PHP güvenlik ekibi, açığın ağırlığı nedeniyle 7.4, 8.0 ve 8.1 için kaynak kodu düzeyinde asgari yamalar da yayınladı; bunlar PHP'yi kaynaktan derleyenler için. Bazı dağıtımlar ve uzun dönem destek sağlayıcıları da geriye dönük yamalar sunabiliyor, bu yüzden bu sürümleri kullananların kendi sağlayıcılarına danışması gerekiyor.

Siteler PHP2Shell Açığından Nasıl Korunur?
Korunma, sıralı birkaç adımdan oluşuyor. Resmi uyarıların ortak noktası, tek tam çözümün güncelleme olduğu.
Envanter çıkarın: FBI'ın tavsiyesine göre önce PHP'nin ortamınızda nerede çalıştığını tespit edin; internete açık sistemlere ve PHP'yi içinde barındıran üçüncü taraf ürünlere öncelik verin.
PHP'yi güncelleyin: Her dal için güvenli sürüme (8.5.12, 8.4.27, 8.3.36 veya 8.2.35) geçin. Resmi duyuruya göre tam koruma yalnızca güncellemeyle sağlanıyor.
Güncelleyemiyorsanız çevrimdışı alın: FBI'ın talimatı net; hemen güncellenemeyen sistem, tamamen giderilene kadar çevrimdışı tutulmalı.
Resmi geçici önlemleri doğru uygulayın: Daubois'nın analizine göre sızıntı sırasında en çok tekrarlanan session.upload_progress.enabled = Off önerisi yalnızca ikinci açığın (CVE-2026-109619) oturum yolunu kapatıyor, birinci açığı değil. Birinci açık için önerilen geçici önlem ise memory_limit=-1 değerini uygulamaların değiştiremeyeceği biçimde zorlamak. Bu önlemler yamanın yerini tutmaz, yalnızca zaman kazandırır.
WAF arkasına alın: Expel'in tavsiyesine göre Cloudflare gibi bir bulut WAF kullanıyorsanız, origin sunucularınızın yalnızca WAF üzerinden trafik kabul ettiğinden emin olun.
Belirti arayın: FBI'ın uyarısına göre PHP süreçlerinin beklenmedik biçimde komut kabuğu başlatması ya da dosya indirmesi gibi şüpheli etkinlikler izlenmeli; belirti görülürse sistem izole edilip loglar saklanmalı.
Sızmış olabilecek sırları yenileyin: Wiz'in gösterdiği bellek ifşası yolu parola, token, API anahtarı ve sertifikaları açığa çıkarabildiği için, etkilenmiş olabilecek sistemlerde bu sırların yenilenmesi makul bir önlem olarak değerlendirilebilir.

Türkiye'deki kurumlar için ek bir boyut da veri koruma yükümlülüğü. Kişisel veri işleyen bir sistemde ihlal tespit edilirse, 6698 sayılı KVKK'nın 12. maddesinin 5. fıkrası gereği durum en kısa sürede ilgililere ve Kişisel Verileri Koruma Kurulu'na bildirilmeli. KVKK'nın kamuoyu duyurusuna göre Kurul'un 2019/10 sayılı kararı, Kurul'a bildirimin ihlalin öğrenilmesinden itibaren en geç 72 saat içinde yapılmasını öngörüyor. Etkilenen kişilere ise makul olan en kısa sürede bildirim yapılmalı. Dolayısıyla PHP2Shell yalnızca teknik değil, hukuki bir olay müdahale planını da gerektiriyor.
İstismar ve Veri Sızıntısı Riski Ne Kadar Büyük?
Bu soruda kaynaklar çelişiyor ve çelişki yöneticiler için kritik. Black Kite'ın derlemesine göre 21 Ekim itibarıyla hiçbir kurum bu açıklardan kaynaklı bir ihlal bildirmedi ve açıklar CISA'nın Bilinen İstismar Edilen Açıklar kataloğunda yer almıyordu.
Öte yandan saldırı trafiği raporları var. The Hacker News'in aktardığına göre Cloudflare, müşterilerini hedefleyen saldırı trafiği gördüğünü ve saldırganların güvenlik duvarı kurallarını aşmak için yüklerini değiştirdiğini açıkladı. SOCRadar'ın derlemesine göre Aikido istismarın sahada rapor edildiğini, Patchstack ise birden fazla aktif istismar vakasını doğruladığını bildirdi; iki şirket de saldırıların teknik ayrıntısını yayımlamadı. watchTowr'ın yayımladığı bilgilere göre şirketin honeypot ağında 21 Ekim itibarıyla aktif istismar gözlendi. The Hacker News'in güncellemesine göre belirli bir sunucuya yönelik teyit edilmiş bir ihlal henüz raporlanmadı, ama saldırı denemeleri çoktan başlamış durumda. Bu, "henüz ihlal yok" rahatlığına kapılmak için değil, hemen yama yapmak için bir gerekçe.

Topluluk Ne Düşünüyor?
Geliştirici tarafında tartışma iki eksende ilerliyor: ifşa süreci ve yapay zekanın rolü. Hacker News tartışmasında bazı kullanıcılar, raporlama ile duyuru arasındaki yaklaşık iki aylık pencereyi bu kadar ciddi bir açık için uzun buldu. Bir kullanıcı ise Calif ile OpenAI'ın açığı aynı gün "bağımsız" olarak bildirmesini fazlasıyla tesadüfi bulduğunu yazdı ve koordineli ifşanın nasıl yürüdüğünü sorguladı.
Sızıntının kendisi de ayrı bir tartışma konusu. Daubois'nın değerlendirmesi bu noktada dengeli bir çerçeve sunuyor: panik, açığın ne kadar ciddi olduğu konusunda haklıydı ama ne yapılması gerektiğini söyleyen ayrıntıların çoğunda yanılıyordu. En çok yayılan geçici önlem önerisinin yanlış açığa ait olması, bir kriz anında doğrulanmamış bilginin nasıl hızla yayıldığını gösteriyor. Daubois'nın bir sonraki sızıntı için önerdiği alışkanlık da bu dersten çıkıyor: ciddiyete güven, önlemi doğrula, bir ayarı kapatmadan önce hangi kod yolunu kapattığını sor.

Sıkça Sorulan Sorular
WordPress veya Laravel sitemi güncellemek açığı kapatır mı?
Hayır. Açık uygulamada değil, onu çalıştıran PHP motorunda. Check Point'in değerlendirmesine göre WordPress, Magento veya Drupal'ı güncellemek tek başına açığı kapatmaz. Çözüm, sunucudaki PHP sürümünü güvenli sürüme yükseltmek.
Paylaşımlı hosting kullanıyorsam ne yapmalıyım?
Paylaşımlı hostingde PHP sürümünü genelde barındırma sağlayıcısı yönetir. Sağlayıcınızın güvenli sürüme (8.5.12, 8.4.27, 8.3.36 veya 8.2.35) geçip geçmediğini sorun. Birçok barındırma panelinde kullanılan PHP sürümü kullanıcı tarafından da görülüp değiştirilebiliyor.
Site ziyaretçileri risk altında mı?
PHP2Shell'in hedefi, etkilenen sürümleri çalıştıran sunucular; doğrudan son kullanıcıların cihazları değil. Ancak sunucu ele geçirilir ve kullanıcı verileri sızarsa, dolaylı olarak ziyaretçiler de etkilenebilir. Bu yüzden yöneticilerin hızlı yama yapması ziyaretçi güvenliği açısından da önemli.
memory_limit=-1 neden öneriliyor, bu güvenliği azaltmaz mı?
İlk bakışta sezgiye ters görünse de mantığı şu: açığın tetiklenmesi için saldırganın bellek sınırının ne zaman aşılacağını öngörmesi gerekiyor. Sınırı kaldırmak bu öngörülebilir başarısızlık anını ortadan kaldırıyor. Bu yalnızca geçici bir önlem; kalıcı çözüm güncelleme.
Açık şu an aktif olarak istismar ediliyor mu?
Saldırı denemeleri var, teyit edilmiş bir ihlal henüz yok. 21 Ekim itibarıyla CISA iki açığı da Bilinen İstismar Edilen Açıklar kataloğuna eklemedi; buna karşın Cloudflare, Aikido, Patchstack ve watchTowr saldırı trafiği veya aktif istismar raporladı. Saldırı denemeleri başladığı için bekleme önerilmiyor.
Yapay zeka modellerinin, on yılı aşkın sürenin en ciddi PHP açığının bulunmasına yardım etmesi savunucular için güçlü bir araç. Aynı hızın saldırganların eline geçmesi ise ayrı bir soru olarak duruyor. Önümüzdeki haftalarda CISA kataloğunun ve yeni istismar raporlarının nasıl değişeceği, bu dengenin hangi tarafa ağır basacağını gösterecek.





