PHP güvenlik açığı php2shell: Hangi sürümler etkileniyor, ne yapmalı?

Bir web sitesinin hangi PHP sürümüyle çalıştığını öğrenmek tek satıra bakar: kendi sunucunuzda php -v, paylaşımlı hostingde ise kontrol panelindeki PHP ayarları sayfası. 21 Ekim akşamından beri o satırın sonundaki sayı çok somut bir şeyi gösteriyor. Sürüm 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35’in altındaysa site, php2shell olarak bilinen PHP güvenlik açığı karşısında korumasız ve kimlik doğrulaması gerektirmeden uzaktan kod çalıştırılmaya açık. “PHP’de kritik açık var” uyarısı doğru ama eksik; site sahibinin işine yarayan bilgi, kendi sürümünün o listenin neresinde durduğu.

İki gün içinde ne oldu?

Açıkların varlığı 20 Ekim’de, yama hazır olmadan internete sızdı. PHP güvenlik ekibi aynı akşam bir ön duyuru yayımlayıp acil güvenlik sürümünü 21 Ekim 14:00 UTC’ye (17:00 TSİ) planladığını açıkladı. Sürümler zamanında çıktı ve ayrıntılar resmî güvenlik bildiriminde paylaşıldı. Araştırmacıların “php2shell” adını verdiği iki açığın kodları CVE-2026-109618 ve CVE-2026-109619; ikisinin de CVSS v4.0 puanı 9,2.

T.C. Siber Güvenlik Başkanlığı da aynı gün TR-26-1372 numaralı bildirimi yayımladı ve ulusal ölçekte tarama başlattığını duyurdu. Bildirimde iki CVE kodu yer alıyor, ancak metin PHP’nin resmî açıklamasından önce hazırlandığı için etkilenen ve düzeltilmiş sürümler henüz içinde değil. Aşağıdaki ayrıntılar o boşluğu PHP’nin kendi kaynaklarından dolduruyor.

Hangi PHP sürümleri etkileniyor?

PHP projesinin teknik bildirimlerine göre iki açık da desteklenen dört dalın aşağıdaki sürümlerden önceki tüm sürümlerini etkiliyor:

PHP dalı	Güvenli sürüm	Not
8.5	8.5.12	Aktif destek
8.4	8.4.27	Aktif destek
8.3	8.3.36	Yalnızca güvenlik desteği
8.2	8.2.35	Desteği 31 Aralık 2026’da bitiyor
8.1, 8.0, 7.x ve öncesi	Resmî sürüm yok	Proje artık güncelleme yayımlamıyor

Desteği bitmiş dallar için iki ayrıntı önemli. PHP güvenlik ekibi, açıkların ciddiyeti nedeniyle 7.4, 8.0 ve 8.1 için kaynak koddan derleyenlere yönelik asgari yamalar yayımladı; hazır paket değil, kodu kendisi derleyen ekipler içindir. Bazı Linux dağıtımları ve uzun süreli destek sağlayıcıları da eski dallara yamayı kendi paketleriyle taşıyor.

İkinci ayrıntı, sürüm numarasının her zaman doğruyu söylememesi. Debian, Ubuntu ve Red Hat gibi dağıtımlar yamayı eski sürüm numarasını koruyarak paketler; php -v “8.2.20” gösterdiği hâlde sistem yamalı olabilir. Dağıtım paketi kullanıyorsanız ölçüt sürüm numarası değil, paket değişiklik kaydında (changelog) iki CVE kodunun geçip geçmediği. Tersi de geçerli: Red Hat tabanlı sistemlerde sık kullanılan gönüllü paket deposu rpms.remirepo.net, PHP’nin bildirimine göre duyuru günü güncellenmedi. O depoya bağlı sunucular için PHP ekibi dağıtım paketlerine geçmeyi ya da kaynaktan derlemeyi öneriyor.

PHP güvenlik açığı nasıl çalışıyor?

İki açığın ortak noktası, PHP’nin bir isteği yarıda bırakmak zorunda kaldığı anlar. CVE-2026-109618’de tetikleyici bellek tükenmesi: PHP, bellek sınırına çarptığında isteği anında keser. Bu kesinti, istekle ilgili bazı iç veriler henüz yarım hazırlanmışken gerçekleşirse istek kapanırken yapılan temizlik o yarım veriyi geçerliymiş gibi işler. PHP’nin bildirimine göre saldırgan, özel hazırlanmış dosya yükleme isteklerinin ayrıştırılması sırasında belleği varsayılan sınırlar içinde kalarak tüketebiliyor.

CVE-2026-109619 ise aynı işlem sürecinin art arda karşıladığı istekler arasında kalan izlerle ilgili. Ölümcül bir hata ya da zaman aşımıyla yarıda kalan bir istek, belleği serbest bırakılmış bir veriye işaret eden iç durum bırakabiliyor. Aynı süreç bir sonraki isteği karşılarken normal hazırlık adımları çalışmadan önce bu eski işaretçiyi kullanabiliyor. İkinci bildirime göre bu yol, varsayılan olarak açık gelen oturum yükleme ilerlemesi özelliğinden geçebiliyor ve uygulamanın session_start() çağırmasına bile gerek kalmıyor.

Her iki açıkta da istismar, uygulama kodu çalışmaya başlamadan önceki aşamada gerçekleşiyor. Açıkları bu kadar tehlikeli yapan da bu. Çoğu açıkta saldırganın önce oturum açmak ya da belirli bir sayfaya ulaşmak gibi engelleri aşması gerekir; burada zayıf nokta, internetten gelen sıradan bir isteğin önünde duruyor. Kilidin nasıl açılacağı bir kez ortaya çıktığında savunmasız sunucuları aramak tek tek değil, otomatik araçlarla binlercesi aynı anda taranarak yapılır. Sitenizin WordPress, Laravel ya da özel yazılım olması bu yüzden sonucu değiştirmiyor; riskin büyüklüğünü belirleyen, PHP’nin web sunucusuna hangi yöntemle bağlandığı:

• Apache + mod_php: İki açık için de kimlik doğrulamasız uzaktan kod çalıştırma doğrulanmış durumda. PHP ekibi riski en yüksek bu kurulumda görüyor.
• PHP-FPM (Nginx ya da Apache arkasında): CVE-2026-109619’un oturum yolu üzerinden kod çalıştırma doğrulanmış. CVE-2026-109618 için kaynak kod incelemesi etkilendiğini gösteriyor, tam istismar henüz gösterilmemiş.
• LiteSpeed (LSAPI) ve FrankenPHP: Kaynak kod incelemesine göre etkilenme olası, istismar doğrulanmamış.

Listenin başındaki kurulum, sahada en yaygın olanı değil. Yeni sunucularda ve güncel panellerde baskın mimari PHP-FPM; mod_php daha çok eski kurulumlarda ve bazı dağıtımlarda Apache ile birlikte gelen varsayılan pakette yaşıyor. FPM kullananların rahatlaması için ise neden yok. İkinci açık FPM’de de kod çalıştırmaya kadar götürülmüş durumda ve doğrulanan yol, varsayılan olarak açık gelen bir özellikten geçiyor. İki kurulum arasındaki fark, saldırının ne kadar güvenilir işlediğinde: mod_php’de iki açık da uçtan uca gösterildi, FPM’de birinci açık için henüz gösterilmedi. Sunucunuzun hangi yöntemi kullandığını phpinfo() çıktısındaki “Server API” satırından görebilirsiniz; bu amaçla oluşturduğunuz dosyayı işiniz bitince silin.

Bütün kurulumlarda başarılı bir saldırının sonucu aynı: saldırgan, web sunucusunun çalıştığı kullanıcı hesabının yetkileriyle komut çalıştırır. Bu yetki çoğu sitede veritabanı bağlantı bilgilerine, yüklenen müşteri dosyalarına ve sitenin kendi koduna erişmeye yeter.

PHP güvenlik açığı şimdiden istismar ediliyor mu?

Kesin bir ele geçirme vakası henüz raporlanmadı, ama deneme aşaması başladı. Güvenlik araştırma şirketi watchTowr, yamanın yayımlanmasından yalnızca 19 dakika sonra her iki açığa yönelik aktif istismar denemeleri gördüğünü açıkladı. Cloudflare ise yama çıkmadan önce müşterilerine yönelik ilk saldırı trafiğini ve saldırganların güvenlik duvarı kurallarını aşmak için içerikleri değiştirdiğini bildirdi. Hollanda’da bazı kamu siteleri ve bir insan kaynakları yazılımı sağlayıcısı, yamalar uygulanana kadar hizmetlerini önlem olarak kapattı. 21 Ekim itibarıyla iki açık da ABD’nin istismar edilen açıklar kataloğunda (CISA KEV) yer almıyordu. İnternette dolaşan kavram kanıtı (PoC) kodlarının bir kısmının çalışıp çalışmadığı doğrulanmış değil.

Önceki bir PHP güvenlik açığı, beklenecek hızı gösteriyor. Haziran 2024’te PHP’nin Windows’taki CGI bileşeninde bulunan CVE-2024-4577 açığı için istismar denemeleri, ayrıntıların kamuya açılmasından sonraki 24 saat içinde başlamıştı. php2shell’de teknik ayrıntılar artık resmî bildirimlerde açıkça yer alıyor; savunanın lehine olan zaman penceresi saatlerle ölçülüyor.

Türkiye’de tablo ne gösteriyor?

İnternete bağlı cihazların kayıtlarını tutan arama motorlarından birinde 22 Ekim’de saydığımızda, Türkiye’de HTTP response header’ında PHP sürüm dalı okunabilen yaklaşık 14.600 sunucu görünüyordu. Bunların yaklaşık 8.650’si, yani %59’u, PHP projesinin artık güncelleme yayımlamadığı 8.1 ve daha eski sürümleri bildiriyor. Tek başına en kalabalık grup, desteği 2020’nin sonunda biten PHP 7.2: yaklaşık 6.150 sunucu. 5.x sürümlerini bildiren sunucu sayısı ise 1.500’ü aşıyor.

Bu sayılar Türkiye’nin genel risk haritası değil. Sürüm bilgisi HTTP response header’ından okunuyor, son haftalarda görülen sunucuları kapsıyor ve yukarıda anlatıldığı gibi dağıtım yamalarını göstermiyor. Daha önemlisi, örneklem kendi kendini seçiyor: önünde içerik dağıtım ağı ya da ters vekil sunucu bulunan, düzgün yapılandırılmış sistemlerin çoğu bu header’ı zaten gizler. Sürümünü dışarıya ilan eden sunucu, temel yapılandırma hijyeni eksik olan sunucudur; yani tablo, bakımı en çok aksayan kesimi gösteriyor. Dünya genelindeki oran da aynı: güvenlik şirketi Mallory, 20 Ekim’de sürüm bildiren yaklaşık 1,5 milyon sunucunun %59’unun 8.1 ya da daha eski sürümde olduğunu hesapladı. Türkiye’de sürümünü ilan eden sunucuların yarısından fazlasının, PHP projesi yarın yeni bir yama yayımlasa bile onu alamayacak bir sürümde çalışması, bakımı unutulmuş sistemlerin ne kadar kalabalık olduğunu gösteriyor. Sürümü gizlemek ise sunucuyu korumaz, yalnızca bu sayımın dışında bırakır. php2shell’in asıl uzun vadeli dersi de bu: desteği biten yazılım, bir sonraki kritik açıkta güncelleme listesinin dışında kalır.

Bir uygulamada açık bulunması kötüdür; binlerce başka yazılımın üzerine kurulduğu bir altyapı bileşeninde bulunması ise bambaşka bir ölçektir. Kritik bir PHP güvenlik açığı bu yüzden dijital asbeste benziyor: işini iyi yaptığı için her yerde bilerek kullanılmış, ama nerede olduğu ilk bakışta belli olmayan, zararı sonradan anlaşılan bir malzeme. Asbestte olduğu gibi iş, sorunun varlığını öğrenmekle başlıyor; tam olarak nerede olduğunu bulup gidermek ise uzun sürebiliyor.

Eski sürümler ise benzetmenin dışında kalıyor, çünkü orada tercih değil ihmal var. Desteği biten bir PHP sürümü çoğu zaman bilinçli bir kararla değil; bütçe ayrılmadığı, sorumlusu değiştiği ya da eski bir eklenti yeni sürümde çalışmadığı için yerinde kalır. Kimse dokunmadıkça sistem kurulduğu günkü hâliyle çalışmaya devam eder ve teknik borç sessizce büyür. Türkiye’deki 7.2 sunucuları, desteğin bitmesinden altı yıl sonra bu borcun canlı örneği.

Kim, ne yapmalı?

Dijital dünya büyük ölçüde aynı parçalarla kuruluyor. Yıllardır kendini kanıtlamış teknolojilere dayanmak bir güç, ama o parçalardan birinde kusur çıktığında durum otomotivdeki geri çağırmalara dönüyor. Farklı marka ve modeller çoğu zaman aynı parçayı kullanır; parça kusurlu çıktığında herkes aracını servise götürmek zorunda kalır. Geri çağırmanın başarılı olması için üreticinin hangi araçta hangi parçanın bulunduğunu bilmesi gerekir. Kurumlar için karşılığı, hangi sistemde hangi PHP sürümünün çalıştığını ve onu kimin güncelleyeceğini bilmek. Saldırıların büyük ölçekli bir dalgaya dönüşüp dönüşmeyeceğini en çok bu hız belirleyecek.

Paylaşımlı hosting kullanıyorsanız PHP’yi siz değil, barındırma firmanız günceller. Panelinizdeki PHP sürümü seçicisinde sitenizin hangi dalı kullandığına bakın; 8.1 ya da altıysa önce test ortamında, sonra canlı sitede desteklenen bir dala geçin. Ardından firmanıza, sunucudaki PHP paketlerinin CVE-2026-109618 ve CVE-2026-109619 yamalarını içerip içermediğini yazılı olarak sorun. WordPress’i, eklentileri ya da temayı güncellemek PHP çalışma ortamını güncellemez; bu iki işi ayrı ayrı düşünün. Panik ortamı sahte uyarılara da zemin hazırlar: barındırma firmanızdan geldiğini söyleyip bir bağlantıdan “PHP yaması” indirmenizi ya da panel bilgilerinizi girmenizi isteyen e-postalara itibar etmeyin. PHP güncellemesi e-postayla gelen bir dosya değildir.

Kendi sunucunuzu ya da konteynerinizi yönetiyorsanız dağıtım paketlerini güncelleyin ya da resmî sürümlere geçin, sonra PHP-FPM, Apache ve benzeri tüm servisleri yeniden başlatın. Yeniden başlatılmayan işlem süreçleri eski kodla çalışmaya devam eder. Konteyner kullanıyorsanız temel imajı yeniden çekip imajları yeniden oluşturmanız gerekir; çalışan konteynerler kendiliğinden güncellenmez. cPanel ya da Plesk gibi panellerin kendi PHP paketlerini getirdiğini, bunların sistem paketlerinden ayrı güncellendiğini unutmayın. Envanteri çıkarırken desteği bitmiş dalları ayrı listeleyin: o sunucular için tek kalıcı çözüm, desteklenen bir dala geçmek.

Bugün güncelleyemiyorsanız PHP’nin önerdiği geçici önlemler riski azaltır, ama ekibin kendi ifadesiyle kurulumu güvenli hâle getirmez. CVE-2026-109619 için session.upload_progress.enabled=0 ayarını php.ini ya da FPM havuz yapılandırmasında yapıp tüm süreçleri yeniden başlatın; ini_set() ya da .user.ini bu iş için yeterli değil. PHP 8.5 kullanıyorsanız fatal_error_backtraces=0 ayarı da bilinen bir yolu kapatır. CVE-2026-109618 için post_max_size değerini düşürün (dosya yükleme gerekmiyorsa 8M, gerekiyorsa 32M) ve upload_max_filesize‘ı bunun altında tutun. Mümkünse web sunucusu ya da ters vekil sunucu katmanında istek boyutu ve çok parçalı istek sınırları koyun. Bellek sınırına ilişkin daha ayrıntılı ayarlar ve uyarıları PHP’nin bildiriminde yer alıyor. Başkanlığın önerdiği adımlar da bu dönemde işe yarar: yönetim arayüzlerini yalnızca güvenilir IP adreslerine açmak ve yurt dışından erişim ihtiyacı olmayan sistemleri uluslararası trafiğe kapatmak.

Güncelledikten sonra işin bittiğini varsaymayın. Denemeler yama çıkmadan önce başladığı için 20 Ekim’den bu yana sunucuda iz aramak gerekiyor: web dizinlerinde son günlerde oluşturulmuş ya da değiştirilmiş beklenmeyen PHP dosyaları, web sunucusu kullanıcısıyla başlatılmış alışılmadık süreçler, kayıtlarda sıra dışı büyüklükte dosya yükleme istekleri ve PHP süreçlerinin bellek hatasıyla art arda çökmesi bunların başında geliyor. Sunucularda bir siber güvenlik ürünü çalışıyorsa son tarama ve tespit kayıtlarını da bu tarih aralığı için gözden geçirin. Şüpheli bir bulgu varsa unutmayın: kapatılan bir PHP güvenlik açığı, saldırganın içeride bıraktığı arka kapıyı kaldırmaz; o noktada konu güncelleme değil, olay müdahalesidir ve fidye yazılımına hazırlık planınızdaki adımlar devreye girer.

Uç noktalarda sürüm takibini ne kadar düzenli yapıyorsak, web sunucularında da aynı düzeni kurmak gerekiyor. Güncel görünen ama geride kalmış cihazları bulma mantığı burada da geçerli: tespit imzası güncel olabilir, altta çalışan yazılım değildir. KOBİ siber hazırlık endeksinde de aynı tablo var: gerçek olayların kaynağı hâlâ kimlik avı, zayıf parolalar ve yamalanmamış sistemler gibi tanıdık sorunlar.

Panik değil, envanter

Kritik bir PHP güvenlik açığı duyurulduğunda en kötü tepki iki uçtan birine düşmek: ya “herkes etkileniyor” diye paniğe kapılmak ya da “bizim sitemiz küçük” diye beklemek. php2shell’de ikisine de gerek yok, çünkü sorunun cevabı tek bir sayıda saklı. Sitenizi kim yönetiyorsa, hosting firması, ajans ya da BT sorumlusu, bugün ona şu soruyu sorun: Sunucularımızdaki PHP hangi sürümde ve CVE-2026-109618 ile CVE-2026-109619 yamalarını içeriyor mu? Cevap “bilmiyorum” ise yapılacak ilk iş belli.