PHP Güvenlik Açığı (PHP2Shell) Nedir? Sitenizi Korumak İçin Yapmanız Gerekenler

PHP2Shell, PHP'nin dosya yükleme isteklerini işleyen çekirdek kodunda bulunan ve saldırganın hiçbir giriş yapmadan sunucuda kod çalıştırmasına izin veren iki kritik açığın adıdır (CVE-2026-109618 ve CVE-2026-109619). Açık, varsayılan PHP ayarlarında çalışıyor, önem puanı 10 üzerinden 9.2 ve PHP ekibi 21 Ekim 2026'da yamayı yayınladı. Tek kalıcı çözüm PHP'yi yamalı sürüme yükseltmektir: 8.5.12, 8.4.27, 8.3.36 veya 8.2.35. Hosting firmalarının e-postayla önerdiği ayar değişikliği yalnızca geçici bir önlemdir.

Bu yazıda açığın ne olduğunu, sitenizin etkilenip etkilenmediğini nasıl anlayacağınızı ve hangi altyapıda ne yapmanız gerektiğini anlatıyorum. Açık duyurulduğu gün kendi sunucumdaki dokuz siteyi yükselttim; yolda çıkan iki sorunu da aşağıya yazdım, çünkü aynı sorunlar sizin karşınıza da çıkabilir.

Ne oldu, kısaca

• 20 Ekim 2026: Açığın ayrıntıları, PHP ekibinin planladığı koordineli duyurudan önce internete sızdı. Kısa süre içinde çalışan bir saldırı kodu da ortaya çıktı.
• 21 Ekim 2026: PHP ekibi desteklenen tüm sürümler için güvenlik yamasını yayınladı. Aynı gün birçok hosting firması müşterilerine acil e-posta gönderdi.
• Sonraki günler: Güvenlik firması watchTowr, tuzak sunucularında açığın gerçek saldırılarda kullanıldığını gördüğünü bildirdi.

Yani bu teorik bir risk değil. Yamasız PHP çalıştıran ve internete açık her site şu an otomatik tarama araçlarının hedefinde.

Türkiye'de durum: Siber Güvenlik Başkanlığı uyarısı

Açık yalnızca yabancı basının gündeminde değil. Siber Güvenlik Başkanlığı, PHP2Shell için ülke genelinde tarama başlattığını ve kurum ve kuruluşlara acil önlem çağrısı yaptığını duyurdu. Önerilen adımlar bu yazıdakilerle aynı: etkilenen sistemleri tespit etmek, yamalı PHP sürümüne geçmek ve yönetim panellerine erişimi güvendiğiniz adreslerle sınırlamak. Avrupa'da bazı kamu kurumları ise yama tamamlanana kadar sitelerini geçici olarak erişime kapattı.

Neden bu kadar ciddi?

Çoğu web açığı belirli bir eklentiye, temaya ya da yanlış yapılmış bir ayara bağlıdır. PHP2Shell öyle değil: sorun PHP'nin kendisinde ve varsayılan ayarlarla çalışıyor. Saldırganın sitenize giriş yapmasına, bir form bulmasına ya da sizin bir hata yapmanıza gerek yok. Sunucuya özel hazırlanmış bir istek göndermesi yetiyor.

"Uzaktan kod çalıştırma" (RCE) şu demek: saldırgan sunucunuzda sizin yerinize komut çalıştırabilir. Pratikte bunun sonucu şunlardan biri olur:

• Sitenize gizli bir arka kapı yerleştirilir; açığı kapatsanız bile içeride kalır.
• Veritabanındaki müşteri, sipariş ve form bilgileri kopyalanır.
• Sitenize spam sayfaları ya da kumar bağlantıları eklenir; Google sitenizi "saldırıya uğramış" diye işaretler.
• Sunucunuz başka sitelere saldırmak ya da kripto para kazmak için kullanılır.

Çözüm bizde: PHP'yi yükseltelim, sitenizin başına Bekçi koyalım

Bu açığın tek kalıcı çözümü PHP'yi yamalı sürüme yükseltmek. Bunu sizin için yapıyoruz: önce tam yedek, sonra test ederek yükseltme, ardından içeri girilip girilmediğinin kontrolü. Ama asıl soru şu: bir sonraki açıkta kim haber verecek?

Bu açıkta yamanın çıkması ile ilk saldırılar arasında saatler vardı. Sitesiyle her gün ilgilenen biri olmayan işletmeler o saatleri kaçırdı; bir kısmı hacklendiğini Google'ın "bu site saldırıya uğramış olabilir" uyarısından ya da müşterisinden öğrenecek.

Bu yüzden kendi sunucumda her gün çalışan bir yapay zeka destekli Sunucu Bekçisi kullanıyorum ve aynısını müşterilerimin sunucularına kuruyorum. Bekçi 15 dakikada bir sitelerin, servislerin ve güvenliğin durumunu kontrol ediyor; sorun varsa acil e-posta gönderiyor, her sabah da yapay zekanın sade Türkçe ile yazdığı bir rapor geliyor. PHP2Shell'den sonra Bekçi'ye PHP yama takibini de ekledim: sitelerinizin PHP sürümü php.net'teki son güvenlik sürümünün gerisinde kalırsa ertesi sabah raporunuzda kritik bulgu olarak görüyorsunuz.

Bekçi'nin yaptıkları kısaca:

• PHP yama takibi: yeni bir güvenlik sürümü çıktığında ya da desteği bitmiş bir PHP kullanıyorsanız uyarır.
• Zararlı dosya taraması: görsel yükleme klasörlerinde çalıştırılabilir dosya (webshell) arar.
• Dosya bütünlüğü: ayar dosyaları, sitenin giriş dosyaları ve SSH anahtarları değişirse haber verir.
• Otomatik IP engelleme: sitenizi ısrarla tarayan bot adreslerini kendiliğinden engeller.
• Kendi kendine onarım: duran bir servisi ya da 502 veren bir siteyi güvenli şekilde yeniden başlatır.
• Günlük tam yedek: her gece veritabanını ve dosyaları sunucu dışına, Google Drive'a yedekler ve yedeğin alındığını denetler.
• Site, SSL ve alan adı takibi: site düşerse, yavaşlarsa ya da sertifika ve alan adı süresi dolmak üzereyse önceden uyarır.

Tüm özellikleri ve örnek günlük raporu güvenlik paketi sayfasında görebilirsiniz. Kurulum hemen yapılır, ilk raporunuz ertesi sabah e-postanıza gelir.

Hangi siteler etkileniyor?

PHP ile çalışan neredeyse her şey: WordPress, WooCommerce, OpenCart, PrestaShop, Joomla, Laravel ile yazılmış siteler ve hazır yazılımların çoğu. Türkiye'deki kurumsal sitelerin ve e-ticaret sitelerinin büyük kısmı PHP üzerinde çalışıyor.

Son satır en kritik olanı. PHP 8.1 ve öncesi artık resmi destek almıyor; bu sürümler için PHP ekibi yama yayınlamıyor. Bazı ticari firmalar eski sürümlere kendi yamalarını sunuyor ama bu bir çözümden çok zaman kazanma yolu. Hâlâ PHP 7.x üzerinde çalışan bir siteniz varsa bu açık, ertelediğiniz yükseltmeyi yapmanın zamanının geldiğini söylüyor.

Kendi sitenizin etkilenip etkilenmediğini adım adım kontrol etmek için 2 dakikalık kontrol listesini kullanabilirsiniz.

PHP nedir, sitem PHP mi kullanıyor?

PHP, web sitelerinin sunucu tarafında çalışan programlama dilidir. Ziyaretçi sitenize girdiğinde sayfayı hazırlayan, formları işleyen ve veritabanıyla konuşan kısım çoğu zaman PHP ile yazılmıştır. WordPress, WooCommerce, OpenCart ve Laravel ile kurulmuş bir siteniz varsa siteniz PHP kullanıyor demektir. Emin değilseniz sitenizi yapan firmaya ya da hosting panelinize bakın; panelde "PHP sürümü" diye bir ayar görüyorsanız cevap evettir.

Sitenizin PHP sürümünü nasıl öğrenirsiniz?

• Hosting paneli: cPanel'de "PHP Sürümünü Seç" (Select PHP Version), Plesk'te alan adının "PHP Ayarları" bölümü, DirectAdmin'de "PHP Version Selector" ekranı mevcut sürümü gösterir.
• WordPress: Yönetim panelinde Araçlar → Site Sağlığı → Bilgi → Sunucu sekmesi PHP sürümünü yazar.
• Sunucuya erişiminiz varsa: komut satırında php -v. Dikkat: komut satırındaki PHP ile sitenin kullandığı PHP farklı olabilir; panelde gördüğünüz sürümü esas alın.

Sürümü öğrenmek için sitenize phpinfo() içeren bir dosya koyduysanız işiniz bitince mutlaka silin. O sayfa saldırganlara sunucunuz hakkında her şeyi anlatır.

Hosting firmanızın e-postası ne diyor, yeterli mi?

Açık duyurulduğunda birçok hosting firması müşterilerine session.upload_progress.enabled = Off ayarını yaptığını bildiren bir e-posta gönderdi. Bu ayar, PHP'nin dosya yükleme sırasında ilerleme bilgisini tuttuğu özelliği kapatır. Açığın tetiklendiği yollardan biri burası olduğu için yama gelene kadar mantıklı bir ilk önlemdi.

Ama iki önemli sınırı var:

1. Tam koruma sağlamıyor. Açığı inceleyen güvenlik firmaları, hiçbir ayar değişikliğinin açığı tamamen kapatmadığını, tek kalıcı çözümün yama olduğunu açıkça yazıyor. Ayar saldırıyı zorlaştırıyor, imkânsız hale getirmiyor.
2. Her sunucuya uygulanamadı. Firmalar ayarı paylaşımlı hosting sunucularına ve kendi yönettikleri sistemlere uyguladı. Yönetimi size ait bir sanal sunucunuz (VPS) varsa, ya da sitenizi 1Panel, aaPanel, CyberPanel gibi bir panelle veya Docker konteynerleriyle çalıştırıyorsanız, firma büyük ihtimalle sunucunuza erişemedi. E-postayı alıp "hallolmuş" diye düşünenlerin önemli bir kısmında ayar hiç yapılmadı.

Benim başıma gelen tam olarak buydu: hosting firmasından e-posta geldi, ama kendi yönettiğim sunucudaki on PHP konteynerinin hepsinde ayar hâlâ açıktı.

Altyapınıza göre ne yapmalısınız?

Paylaşımlı hosting kullanıyorsanız

PHP sürümünü hosting firması yönetir. Yapmanız gereken iki şey var: panelden sitenizin hangi PHP sürümünü kullandığına bakın ve firmaya yamalı sürümün (8.4.27, 8.3.36 gibi) ne zaman kurulacağını sorun. Paneliniz sürüm seçmenize izin veriyorsa ve siteniz hâlâ 7.4 veya 8.0 gibi eski bir sürümdeyse, desteklenen bir sürüme geçmeden önce sitenizin yeni sürümle uyumlu olduğunu test ettirin.

Kendi sunucunuz (VPS) varsa

İşletim sisteminizin paket yöneticisiyle PHP'yi güncelleyin ve PHP-FPM servisini yeniden başlatın. PHP'yi işletim sisteminin kendi deposundan değil de ek bir depodan kurduysanız (Ubuntu ve Debian'da sık kullanılan Ondřej Surý deposu gibi), yamalı sürümün o depoya gelip gelmediğini kontrol edin. AlmaLinux, yamalı paketlerini 21 Ekim'de yayınladı. Güncellemeden sonra php-fpm -v ile sitenin gerçekten yeni sürümle çalıştığını doğrulayın.

Docker veya 1Panel gibi bir panel kullanıyorsanız

Kendi sunucumda tam olarak bu düzen vardı: her site için ayrı bir PHP konteyneri. Yükseltmede karşılaştığım iki sorun, bu düzende çalışan herkesin başına gelebilir:

• Site 502 hatası verdi. Yeni resmi PHP Docker imajlarında, PHP'nin konteyner dışından gelen bağlantıları dinlemesini sağlayan ayar varsayılan dosyadan kaldırılmış. Panelin kendi ayar dosyası PHP'yi yalnızca konteynerin içine dinletiyordu; web sunucusu PHP'ye ulaşamadı. Çözüm, imaja PHP-FPM'in 9000 portunu dinlemesini söyleyen tek satırlık bir ayar eklemekti. Bunu bilmeden yükseltirseniz site anında düşer.
• Yönetim panelinde görsel yükleme bozuldu. Eski konteynerlere sonradan panel üzerinden eklenmiş bir PHP eklentisi (intl), konteyner yeni imajla yeniden oluşturulunca kayboldu. Site açılıyordu ama yönetim panelinin bazı ekranları hata veriyordu. Panelden eklediğiniz her eklenti konteynerle birlikte silinir; yükseltmeden önce mevcut konteynerde php -m ile tam eklenti listesini alın ve yeni imajda aynısını kurun.

Önerim: önce tek bir sitede deneyin, ana sayfayı, yönetim panelini ve bir form gönderimini test edin, sonra diğerlerine geçin. Eski imajı silmeyin; bir sorun çıkarsa geri dönüş tek komut olur.

Yamadan sonra: içeri girilmiş mi?

Açık yama çıkmadan bir gün önce yayıldı ve gerçek saldırılarda kullanıldığı bildirildi. Yamayı yapmak kapıyı kapatır ama içeri girmiş birini çıkarmaz. Şu kontrolleri yapın:

• Yükleme klasörlerinde PHP dosyası: wp-content/uploads, storage, images gibi yalnızca görsel olması gereken klasörlerde .php uzantılı dosya olmamalı.
• Son günlerde değişmiş dosyalar: 20 Ekim'den bu yana sizin değiştirmediğiniz dosyalar var mı? Sunucuda find . -name "*.php" -mtime -5 komutu son 5 günde değişen PHP dosyalarını listeler.
• Yeni yönetici hesapları: WordPress'te ve diğer panellerde tanımadığınız bir yönetici var mı?
• Zamanlanmış görevler: Sunucunun cron listesine sizin eklemediğiniz bir görev eklenmiş mi?
• Erişim kayıtları: 20 Ekim'den itibaren olağan dışı büyüklükte ya da çok sayıda dosya yükleme isteği var mı?

Bunlardan biri tutarsa, yalnızca şüpheli dosyayı silmek yetmez. Arka kapılar genelde birden fazla yere yerleştirilir. Siteyi temiz bir yedekten geri yüklemek, tüm şifreleri ve veritabanı parolasını değiştirmek gerekir.

Bir sonraki açıkta daha hazırlıklı olmak için

• PHP sürümünüzü saklayın. php.ini dosyasında expose_php = Off ayarı, sunucunuzun her yanıtta PHP sürümünü X-Powered-By başlığıyla duyurmasını engeller. Otomatik tarayıcılar hedef seçerken ilk bu başlığa bakar.
• Desteklenen bir sürümde kalın. Resmi desteği bitmiş bir PHP sürümü, bir sonraki açıkta yamasız kalacağınız anlamına gelir.
• Güvenlik duyurularını takip eden biri olsun. Bu açıkta yamanın çıkması ile ilk saldırılar arasında saatler vardı. Siteyle ilgilenen kimse yoksa bu saatler fark edilmeden geçer.
• Yedeğinizi sunucunun dışında tutun. Sunucu ele geçirilirse aynı sunucudaki yedek de güvenilir değildir.

Kritik PHP açığına çözüm bizde

Sitenizin PHP sürümünü kontrol edip, önce yedek alıp, test ederek yamalı sürüme yükseltiyorum; ardından iz kontrolü yapıp sunucunuza yapay zeka destekli Sunucu Bekçisi'ni kuruyorum. VPS, Docker ve panel tabanlı kurulumlarda yukarıda anlattığım tuzaklar dahil. Hemen başlıyoruz: güvenlik paketi (PHP yükseltme dahil) sabit 9.500 TL, Bekçi AI ayda yalnızca 249 TL ve ilk ay ücretsiz deneme.

Önce kendiniz bakmak isterseniz ücretsiz güvenlik analizi sitenizin dışarıya sürüm bilgisi verip vermediğini ve eksik güvenlik başlıklarını gösterir.

PHP yükseltme + Sunucu Bekçisi · WhatsApp'tan yazın · iletişim formu

Sıkça Sorulan Sorular

PHP2Shell nedir?
PHP2Shell, PHP'nin çekirdeğinde dosya yükleme isteklerini işleyen kodda bulunan iki kritik açığın (CVE-2026-109618 ve CVE-2026-109619) adıdır. Saldırganın giriş yapmadan sunucuda kod çalıştırmasına izin verir ve varsayılan PHP ayarlarında çalışır. PHP ekibi 21 Ekim 2026'da yamayı yayınladı.

Hosting firmamın yaptığı session.upload_progress ayarı yeterli mi?
Hayır, yalnızca geçici bir önlemdir. Saldırıyı zorlaştırır ama güvenlik firmalarına göre açığı tamamen kapatmaz. Kalıcı çözüm PHP'yi 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 sürümüne yükseltmektir. Ayrıca bu ayar yalnızca firmanın erişebildiği sunuculara uygulandı; kendi yönettiğiniz bir VPS'te yapılmamış olabilir.

WordPress sitem etkileniyor mu?
Evet. Açık WordPress'te değil, onu çalıştıran PHP'de. WordPress'i ya da eklentileri güncellemek bu açığı kapatmaz; sunucudaki PHP sürümünün yamalı olması gerekir. Sürümü yönetim panelinde Araçlar → Site Sağlığı → Bilgi → Sunucu bölümünden görebilirsiniz.

PHP 7.4 kullanıyorum, ne yapmalıyım?
PHP 7.4'ün resmi desteği bittiği için bu açık için resmi yama yayınlanmadı. Desteklenen bir sürüme (8.3 veya 8.4) geçmeniz gerekiyor. Geçişten önce sitenizin, temanızın ve eklentilerinizin yeni sürümle uyumlu olduğu bir test ortamında denenmeli; eski kodlar PHP 8'de hata verebilir.

PHP'yi güncellemek sitemi bozar mı?
Aynı ana sürüm içindeki yama güncellemesi (örneğin 8.4.6'dan 8.4.27'ye) genelde sorunsuzdur, çünkü yalnızca hata ve güvenlik düzeltmeleri içerir. Risk, sunucunun yeniden kurulduğu durumlarda kaybolan eklentiler ve ayarlardadır. 7.x'ten 8.x'e geçiş ise kod uyumluluğu gerektirdiği için mutlaka test edilmelidir.

Sitemin saldırıya uğrayıp uğramadığını nasıl anlarım?
Görsel klasörlerinde PHP dosyası olup olmadığına, 20 Ekim'den bu yana sizin değiştirmediğiniz dosyalara, tanımadığınız yönetici hesaplarına ve sunucudaki zamanlanmış görevlere bakın. Şüpheli bir bulgu varsa yalnızca o dosyayı silmek yetmez; temiz yedekten geri yükleyip tüm şifreleri değiştirmeniz gerekir.