PHP2Shell Nedir? PHP Güvenlik Açığı ve Yapman Gerekenler

PHP2Shell, PHP'nin kendisinde bulunan iki kritik açığa verilen ad. Bu PHP güvenlik açığı, saldırganın hiçbir kullanıcı adı ya da parola girmeden sunucuda kendi kodunu çalıştırmasına izin verebiliyor. Yamalar 21 Ekim 2026'da yayımlandı ve aynı gün saldırı girişimleri görülmeye başlandı. WordPress dahil PHP ile çalışan hemen her siteyi ilgilendirdiği için bu yazıda neyin kesin olduğunu, sürümünü nasıl kontrol edeceğini ve adım adım ne yapman gerektiğini anlatıyorum.

Bir bakışta

Açıklar: CVE-2026-109618 ve CVE-2026-109619
Önem: CVSS v4.0 puanı 9.2 (kritik), oturum açmadan uzaktan kod çalıştırma
Yamalı sürümler: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 (21 Ekim 2026)
PHP 8.1 ve öncesi: Resmî yeni sürüm yok; yalnızca kaynak kod yamaları ve dağıtım paketleri
Durum: Saldırılarda kullanılıyor; ABD siber güvenlik ajansı CISA 26 Ekim'de "istismar edildiği bilinen açıklar" kataloğuna ekledi

Kısa cevap

PHP sürümün yukarıdaki yamalı sürümlerden eskiyse hemen güncelle ve PHP'yi yeniden başlat. PHP ekibinin açıklamasına göre hiçbir ayar değişikliği bu açığı tamamen kapatmıyor; tek kalıcı çözüm güncelleme.

PHP2Shell nedir?

PHP2Shell, WordPress'te, bir eklentide ya da senin yazdığın kodda değil, doğrudan PHP'nin çekirdeğinde bulunan iki açığın ortak adı. Ad, açığı istismar etmek için hazırlanan bir araçtan geliyor; PHP'nin resmî güvenlik bildirimlerinde açıklar "RCE via OOM corruption" ve "RCE via stale global state" başlıklarıyla yer alıyor. İkisinin de sonucu aynı: saldırgan sunucuda kendi kodunu çalıştırabilir.

CVE-2026-109618: bellek yetersizliğinde bozulma

PHP bir isteği işlerken bellek sınırına takılırsa işlem yarıda kesilebiliyor. Bu açıkta, istek sonundaki temizlik adımı yarım kalmış verileri geçerliymiş gibi işliyor. Saldırgan bu durumu bilerek tetikleyip sunucuda kod çalıştırabiliyor.

CVE-2026-109619: bir istekten kalan bayat veri

İkinci açıkta, bir isteğe ait veri bellekten silindikten sonra da kullanılabiliyor. Aynı PHP işçisinin karşıladığı bir sonraki istek, sıfırlanmamış bu "bayat" veriye ulaşabiliyor. Sonuç yine uzaktan kod çalıştırma.

Hangi PHP sürümleri etkileniyor?

Bu PHP güvenlik açığı, web isteği sunan bütün PHP kurulumlarını etkiliyor: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed ve FrankenPHP. Kaynaklar en yüksek riski Apache mod_php'de görüyor; çünkü orada saldırı, sitenin kendi kodu hiç çalışmadan başarılı olabiliyor. Etkilenen ve yamalı sürümler şöyle:

PHP dalı	Etkilenen sürümler	Yamalı sürüm
8.5	8.5.12'den eski	8.5.12
8.4	8.4.27'den eski	8.4.27
8.3	8.3.36'dan eski	8.3.36
8.2	8.2.35'ten eski	8.2.35
8.1, 8.0 ve 7.4	Tüm sürümler	Resmî sürüm yok, yalnızca kaynak kod yaması
7.3 ve öncesi (PHP 5 dahil)	Tüm sürümler	Yok

Sorunun ne kadar yaygın olduğuna dair bir fikir: güvenlik firması Brandefense, 21–25 Ekim arasında 30.027 sitede yaptığı ölçümde PHP sürümünü açıkça gösteren 3.532 sitenin yüzde 59'unun yamadan eski bir sürüm bildirdiğini açıkladı. Bunların yüzde 26'sı desteklenen ama yamasız bir sürümdeydi, yüzde 33'ü ise desteği bitmiş 8.1 ve öncesinde.

Neden bu kadar acil?

PHP güvenlik açığının ayrıntıları 20 Ekim'de, planlanan 22 Ekim duyurusundan önce internete sızdı. PHP ekibi bunun üzerine yamaları öne çekti ve 21 Ekim'de Türkiye saatiyle 17.00'de yayımladı. Güvenlik firması watchTowr, aynı gün itibarıyla açığın gerçek saldırılarda kullanıldığını gözlemledi. CISA da 26 Ekim'de açığı istismar edildiği bilinen açıklar listesine ekledi.

Türkiye'de de konu gündemde. Indigo Dergisi'nin aktardığına göre Cumhurbaşkanlığı Siber Güvenlik Başkanlığı 21 Ekim'de kritik bir uyarı yayımladı. Uyarıda yamalı sürümlere geçilmesi ve yönetim panellerine erişimin güvenilir IP adresleriyle sınırlandırılması önerildi. Google aramalarında da "php açığı" ve "php güvenlik açığı" sorguları son haftalarda sert biçimde yükseldi.

PHP sürümünü nasıl kontrol edersin?

Önemli olan, sitenin web isteklerini karşılayan PHP sürümü. Sunucuda birden fazla PHP sürümü kurulu olabilir ve her alan adı farklı birini kullanıyor olabilir.

cPanel'de

MultiPHP Yöneticisi ekranı, her alan adının kullandığı PHP sürümünü gösterir. CloudLinux kullanan sunucularda aynı bilgi PHP Sürümünü Seç ekranındadır. cPanel sunucularında PHP paketleri ea-php, CloudLinux'ta alt-php adını taşır; ikisi için de yamalı paketler yayımlandı.

WordPress'te

Yönetim panelinde Araçlar > Site Sağlığı > Bilgi > Sunucu bölümüne git. "PHP sürümü" satırı sitenin gerçekte kullandığı sürümü gösterir. Paylaşımlı hostingdeysen bu en kolay yoldur.

Sunucuda komut satırından

php -v komutu yalnızca komut satırındaki PHP'yi gösterir; web sitesinin kullandığı sürüm farklı olabilir. Web tarafında kullanılan sürümü panelden ya da PHP-FPM için php-fpm -v ile doğrula. Linux dağıtımlarının paketleri yamayı eski sürüm numarasını koruyarak getirebilir. Bu durumda sürüm numarasına değil, paketin değişiklik kaydına ya da sağlayıcının açıklamasına bak.

Sunucuda phpinfo dosyası bırakma

Tarama araçları bu açık için özellikle /phpinfo.php, /info.php ve /test.php gibi dosyaları arıyor. Sürümü görmek için böyle bir dosya oluşturduysan işin bitince hemen sil.

Adım adım yapman gerekenler

Sürümünü öğren. Yukarıdaki yollardan biriyle sitenin kullandığı PHP sürümünü bul.
Yamalı sürüme geç. Aynı dalın yamalı sürümüne güncelle: 8.3 kullanıyorsan 8.3.36 ya da üstü gibi. Paylaşımlı hostingdeysen sağlayıcına 21 Ekim güncellemelerinin uygulanıp uygulanmadığını yazılı olarak sor.
PHP'yi yeniden başlat. Çalışan PHP işlemleri eski kodu bellekte tutar. PHP-FPM, LiteSpeed ya da Apache hizmetini yeniden başlat; birden çok PHP sürümü varsa her birini.
8.1 ve öncesindeysen planlı geçiş yap. Siteyi önce bir kopya ortamda PHP 8.3 ya da 8.4 ile dene, tema ve eklenti uyumunu gör, sonra canlıya al. Geçiş hemen mümkün değilse dağıtımının ya da CloudLinux, TuxCare gibi uzun süreli destek sağlayıcılarının yamalı paketlerini kullan.
Yönetim panellerini kısıtla. wp-admin, phpMyAdmin ve cPanel gibi panellere yalnızca güvenilir IP adreslerinden erişilebilsin.
Kayıtları kontrol et. Aşağıdaki saldırı belirtilerine göz at.

Hemen güncelleyemiyorsan: ara önlemler

PHP ekibi geçici önlemler önerdi ama bunların tam çözüm olmadığını açıkça belirtti. Bu ayarları yalnızca güncellemeye kadar geçen kısa süre için kullan:

session.upload_progress.enabled = 0 ayarını php.ini dosyasında, PHP-FPM havuzunda ya da sunucu ayarında yap ve bütün PHP işçilerini yeniden başlat. ini_set() ya da .user.ini ile verilen değer işe yaramaz. Bu ayar bilinen saldırı yolunu kapatır, ama her türevi değil.
Dosya yükleme gerekmiyorsa post_max_size = 8M, gerekiyorsa post_max_size = 32M kullan ve upload_max_filesize değerini bunun altında tut.
PHP 8.5 kullanıyorsan fatal_error_backtraces = 0 ayarını ekle.
Hata mesajlarını gizlemek (display_errors ya da @ işareti) bu açığa karşı işe yaramaz.
Cloudflare gibi bir web uygulama güvenlik duvarı saldırı trafiğinin bir kısmını engelleyebilir, ama PHP'deki açığı kapatmaz.

; php.ini veya PHP-FPM havuzu — yalnızca güncellemeye kadarsession.upload_progress.enabled = 0post_max_size = 8Mupload_max_filesize = 6M

Brandefense'in aktardığına göre 23 Ekim'de oturum yükleme ilerlemesi özelliğiyle ilgili üçüncü bir açık (CVE-2026-115560) duyuruldu ve 21 Ekim sürümleri bunu kapatmıyor. Ayrıntılar netleşene kadar session.upload_progress.enabled ayarını güncellemeden sonra da kapalı tutmak mantıklı.

Saldırıya uğradın mı? Belirtiler

Güvenlik firmalarının yakaladığı saldırı trafiğinde bazı ortak izler var. Sunucu erişim ve hata kayıtlarında şunlara bak:

Tarayıcı kimliğinde php2shell-scan, php2shell-verify ya da php2shell-poc geçen istekler.
/index.php adresine gelen, bellek sınırı hatasıyla biten çok parçalı (multipart) POST istekleri ve ardı ardına gelen HTTP 500 hataları.
/phpinfo.php, /info.php, /test.php ya da /php2shell-probe- ile başlayan adreslere istekler.
Oturum klasöründe içeriği PHP kodu olan sess_ dosyaları; bir yanıtta PWNED:: ifadesinin görünmesi.
Web kök klasöründe tanımadığın PHP dosyaları, yeni zamanlanmış görevler (cron) ya da yeni kullanıcı hesapları.
PHP işlemlerinin komut satırı çalıştırması ya da dışarıya beklenmedik bağlantılar açması.

Unutma: varsayılan kayıtlar POST isteklerinin içeriğini tutmaz. Kayıtlarda iz bulamaman, saldırı olmadığının kesin kanıtı değildir. Ayrıca saldırganın gönderdiği adresler ve kimlikler kolayca değiştirilebildiği için bu listeyi bir başlangıç noktası olarak gör.

Saldırı izi bulursan ne yapmalısın?

Siteyi yalıt. Gerekirse siteyi bakım moduna al ya da geçici olarak kapat.
Kayıtları sakla. Temizliğe başlamadan önce erişim ve hata kayıtlarının bir kopyasını al; sonradan neyin olduğunu anlamak için gerekecek.
PHP'yi güncelle ve temizle. Yamalı sürüme geç, tanımadığın dosyaları kaldır ya da siteyi temiz bir yedekten geri yükle.
Bütün gizli bilgileri değiştir. Sunucu belleğinde parolalar, oturum anahtarları ve API anahtarları bulunabilir. Veritabanı parolasını, yönetici parolalarını ve API anahtarlarını yenile.
Hosting sağlayıcına haber ver. Paylaşımlı bir sunucudaysan aynı sunucudaki diğer siteler de etkilenmiş olabilir.

WordPress kullanıyorum, ne yapmalıyım?

Açık WordPress'te değil, sunucudaki PHP'de olduğu için WordPress'i ya da eklentileri güncellemek bu PHP güvenlik açığını kapatmaz. Güvenlik firması VulnCheck, yamasız PHP 8.2–8.5 sürümleriyle çalışan varsayılan WordPress Docker kurulumlarında istismarın mümkün olduğunu gösterdi. Yapman gereken, Site Sağlığı ekranından PHP sürümünü kontrol etmek ve gerekirse hosting panelinden ya da sağlayıcın aracılığıyla yamalı sürüme geçmek. Saldırıdan şüpheleniyorsan wp-config.php içindeki güvenlik anahtarlarını (salt) yenile; böylece açık oturumların hepsi kapanır.

Sık sorulan sorular

PHP2Shell yalnızca WordPress sitelerini mi etkiliyor?

Hayır. Açık PHP'nin çekirdeğinde olduğu için WordPress, Laravel, hazır PHP scriptleri ya da elle yazılmış siteler fark etmeksizin web isteği sunan her PHP kurulumu risk altında.

Sitem PHP sürümünü göstermiyor, güvende miyim?

Hayır. Sürümün dışarıdan görünmemesi güvende olduğun anlamına gelmez. Sürümü panelden ya da Site Sağlığı ekranından kendin kontrol et.

Paylaşımlı hosting kullanıyorum, ne yapmalıyım?

cPanel'de MultiPHP Yöneticisi'nden sürümünü kontrol et ve sağlayıcına yamalı paketlerin kurulup PHP'nin yeniden başlatıldığını yazılı olarak sor. Bazı sağlayıcılar yalnızca geçici ayar değişikliği yaptı; bu tam çözüm değil.

PHP 7.4 ya da 8.1 kullanıyorum, yama var mı?

PHP ekibi bu sürümler için yeni bir sürüm yayımlamadı; yalnızca 7.4, 8.0 ve 8.1 için kaynak kod yamaları paylaştı. Dağıtımlar ve uzun süreli destek sağlayıcıları yamalı paketler sunuyor, ama kalıcı çözüm desteklenen bir sürüme, tercihen 8.3 ya da 8.4'e geçmek.

Cloudflare kullanıyorum, yeterli mi?

Yeterli değil. Bir güvenlik duvarı saldırı trafiğinin bir kısmını durdurabilir, ama sunucudaki PHP açığını kapatmaz. Güncelleme yine şart.

Güncelledim, başka bir şey yapmam gerekiyor mu?

PHP'yi yeniden başlattığından emin ol, ardından kayıtları saldırı belirtilerine karşı kontrol et. Güncellemeden önce saldırıya uğramış olabileceğin için temiz bir sürüm, temiz bir sunucu anlamına gelmez.

Sonuç

PHP2Shell, son yılların en kritik PHP açıklarından biri ve saldırılarda kullanılıyor. Yapılacak iş net: sürümünü öğren, yamalı sürüme geç, PHP'yi yeniden başlat ve kayıtlarını kontrol et. 8.1 ve öncesindeki siteler için desteklenen bir sürüme geçişi artık ertelememek gerekiyor. Genel güvenlik alışkanlıkları için PHP scriptlerde güvenliğin 12 altın kuralı ve PDO ile güvenli sorgu yazma yazılarımıza da göz atabilirsin. Sorularını iletişim sayfamızdan iletebilirsin.

Bu yazı 1 Kasım 2026 itibarıyla bilinenlere göre hazırlandı; yeni gelişmelerde güncellenecek.