PHP2Shell Açığı Nedir, Nasıl Kapatılır

21 Ekim 2026’da PHP ekibi, güvenlik dünyasında PHP2Shell diye anılan iki kritik açık için acil durum güncellemesi yayımladı. Bu açıklar sayesinde saldırgan, giriş yapmasına gerek kalmadan web sunucunda kod çalıştırabiliyor. Üstelik ayrıntılar yama yayımlanmadan önce sızdı. Laravel, Symfony, WordPress ya da kendi yazdığın bir uygulama olsun, altında çalışan PHP sürümü güncel değilse risk altındasın. Bu yazıda PHP2Shell’in ne olduğunu, sunucunun etkilenip etkilenmediğinin nasıl kontrol edildiğini, açığın nasıl kapatıldığını ve bir dahaki sefere hazırlıklı olmak için neler yapılabileceğini anlatıyorum.

PHP2Shell nedir

PHP2Shell, PHP yorumlayıcısının kendisindeki iki açığa verilen takma ad. Bu açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarını taşıyor. İkisi de CVSS v4.0 ölçeğinde 9,2 puan alıyor ve kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya yol açabiliyor. Yani internet üzerinden sitene ulaşabilen biri, şifre ya da hesap olmadan sunucunda kendi komutlarını çalıştırabilir.

İki açığın çalışma biçimi farklı.

• CVE-2026-109618 bellek yetersizliği hatası sırasında oluşan bellek bozulması. PHP, bellek sınırını aşan isteği yarıda keserek durdurur. Bu kesinti, istek verisi henüz yarım kurulmuşken gelirse (örneğin bir dosya yükleme isteği ayrıştırılırken), temizlik kodu hiç hazırlanmamış bir belleği serbest bırakmaya çalışabilir. O bellekte de saldırganın daha önce yerleştirdiği veri durabilir.
• CVE-2026-109619 eski durumun geride kalması. İstek sırasında oluşan bazı iç durumlar, bağlı oldukları bellek serbest kaldıktan sonra da yaşamaya devam edebilir (ölümcül bir hatadan sonra olduğu gibi). Aynı worker tarafından işlenen bir sonraki istek, PHP kendi başlangıç ayarlarını yapmadan önce bu artık durumu kullanabilir.

Bir otelde temizlik görevlisinin odayı yarım bırakıp başka bir işe çağrıldığını düşün. Sonraki misafire anahtar, oda sıfırlanmadan verilirse o misafir öncekinin bıraktığı her şeyi devralır. PHP2Shell, bu türden bir karışıklığı kod çalıştırmaya çeviriyor.

Uygulama güncellemeleri neden yetmiyor

Uygulaman, framework’ün ve Composer paketlerin PHP ile yazılmış programlar. Hepsi PHP çalışma zamanının üzerinde koşuyor, PHP2Shell ise bu çalışma zamanının içinde. Laravel, Symfony, WordPress ya da herhangi bir paketi güncellemek bu açığa dokunmaz. WordPress.org da bu konuda bir WordPress güncellemesinin gerekmediğini ve planlanmadığını doğruladı. Çözüm bir PHP güncellemesi. Yönetilen ve paylaşımlı hostinglerde bunu hosting firması yapar, VPS’te ya da konteynerde ise iş sana düşer.

PHP, web isteğine hizmet veren her kurulumun risk altında olduğunu söylüyor. PHP-FPM, Apache ile mod_php, php-cgi, FrankenPHP ve LiteSpeed fark etmiyor. En riskli yapı mod_php. Gösterilen bir istismar yöntemi, tek bir kimliksiz isteğin uygulama kodu daha çalışmadan saldırıyı tetikleyebildiğini ortaya koyuyor. Bu durumda uygulama katmanındaki güvenlik kontrolleri, giriş ekranı ya da framework middleware’i devreye bile girmiyor.

Zaman çizelgesi aciliyeti açıklıyor.

• 20 Ekim. PHP ekibi ertesi gün için kritik bir güvenlik sürümü yayımlayacağını duyurdu ve ayrıntıları paylaşmadı.
• Yayından önce. Kamuya açık raporlar açıkların uzaktan kod çalıştırmaya yol açabileceğini söyledi, istismar ayrıntıları dolaşmaya başladı.
• 21 Ekim. PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 yayımlandı. Cloudflare o sabah erken saldırılar gördüğünü bildirdi, CISA ise yayın anında istismar gözlemlemediğini açıkladı. Raporlar birbirini tutmuyor, bu yüzden ikisini de bugün yama yapmak için yeterli sebep say.

Sunucunun etkilenip etkilenmediğini kontrol etme

İlk adım PHP sürümüne bakmak. Yönettiğin bir sunucuda komut satırı sürümü için php -v, web sunucusunun gerçekte kullandığı sürüm için php-fpm8.3 -v çalıştırılır (dalı kendi sürümüne göre değiştir). İkisi birbirinden farklı çıkabilir. Paylaşımlı hostingte sürüm kontrol panelinde görünür, birçok CMS ve framework yönetim ekranı da bunu listeler.

Sürümü tabloyla karşılaştır. Burada önemli bir ayrıntı var. Linux dağıtımları PHP’yi çoğu zaman yerinde yamalar ve eski sürüm numarasını korur. Örneğin Ubuntu 24.04 8.3.6 yazıp düzeltmeyi taşıyor olabilir. Yani eski görünen bir numara açık olduğunu kanıtlamaz, yeni görünen bir numaranın da doğrulanması gerekir. Debian ve Ubuntu’da düzeltme pakete girmişse changelog dosyasında CVE numaraları geçer.

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

Komut eşleşen satırlar yazdırıyorsa paket düzeltmeyi içeriyor demektir. Searchlight Cyber ayrıca php2shell-scanner adında açık kaynaklı bir tarayıcı yayımladı. Bu araç bir sunucunun iki açıktan etkilenip etkilenmediğini test ediyor, birden fazla sunucu yönetiyorsan işine yarar.

PHP nasıl güncellenir

İzlenecek yol, sunucunu kimin yönettiğine göre değişiyor.

• Yönetilen hosting. PHP güncellemesini hosting firması yapar. GoDaddy ve Pressable dahil birkaç yönetilen hosting 21 Ekim’de açıklama yayımladı. Hostingin durum sayfasına ya da e-postalarına bak, hiçbir şey gelmediyse destek ekibine yaz.
• Paylaşımlı hosting. Sunucuda herkes için tek bir PHP çalışır ve düzeltmeyi hosting firması uygular. Birçok cPanel hostingin altındaki CloudLinux, yamalı paketleri resmi sürümden biraz sonra yayımlıyor. Bu yüzden destekten 21 Ekim sürümünün uygulanıp uygulanmadığını sor. Birçok kontrol paneli PHP sürümünü kendin seçmene de izin verir.
• VPS veya kendi sunucun. Senin yerine kimse yama yapmaz. Önce snapshot al, sonra güncelle.

Konteynerlerde çalışan bir uygulama, konteyner değiştirilene kadar eski PHP’yi kullanmaya devam eder. İmaj, düzeltilmiş PHP sürümü içeren bir temel etiketten yeniden build edilir, konteynerin içinde php -v ile doğrulanır ve yeniden dağıtılır. Paneller de kendi güncellemelerini yayımlıyor. Plesk, düzeltilmiş PHP 8.2 ile 8.5 sürümlerini çıkardı. Laravel Forge’da her PHP sürümünü sunucu sayfasından kendin güncellersin.

Ondřej Surý deposundan gelen PHP 8.3 için Ubuntu’da güncelleme şu komutlarla yapılır (8.3 yerine kendi dalını yaz):

sudo apt update
apt-cache policy php8.3-fpm
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
php-fpm8.3 -v

İkinci komutun çıktısındaki Candidate satırında 8.3.36 görünmeli. Yayın gününde bu deponun bazı yansıları geriden geldi. Yeni sürüm görünmüyorsa sunucunun hangi paket kaynağını kullandığına bakılır. Red Hat ailesi sistemler için gönüllülerin yürüttüğü Remi deposunda da yayın gününde güncelleme yoktu. PHP bu kullanıcılara dağıtım paketlerine geçmelerini ya da kaynaktan derlemelerini önerdi.

PHP 8.1 ve daha eski sürümlerde durum daha zor. PHP projesi bu dallar için sürüm yayımlamadı. Bazı dağıtımlar ve uzun dönem destek sağlayıcıları düzeltmeyi eski sürümlere taşıyor, PHP de 7.4, 8.0 ve 8.1 için asgari kaynak yamaları yayımladı. Çoğu site için asıl çözüm 8.3 ya da daha yeni bir sürüme geçmek. Eski bağımlılıklar yeni PHP’de bozulabilir. Bu yüzden yükseltme önce bir staging kopyasında denenir, kırılanlar düzeltilir ve ancak ondan sonra canlı siteye geçilir.

Hemen güncelleyemiyorsan

PHP, güncellemenin tek güvenli yol olduğunu ve tam bir geçici çözüm bulunmadığını söylüyor. Bugün güncellenemeyen bir sunucu için PHP’nin duyurusunda, belirli saldırı yollarını daraltan önlemler sıralanıyor.

• session.upload_progress.enabled = 0 ayarı php.ini’de, PHP-FPM havuzunda ya da sunucu yapılandırmasında yapılır, ardından tüm worker’lar yeniden başlatılır. Bu, CVE-2026-109619 için doğrulanmış oturum yollarını kapatır. Çoğu uygulama bu özelliği kullanmaz, yine de kapatmadan önce kendi uygulamanı kontrol et. Ayar ini_set() ya da .user.ini ile yapılırsa işe yaramaz, çünkü istek ayrıştırılmadan önce geçerli olması gerekir.
• post_max_size düşük tutulur. Büyük dosya yüklemesi gerektirmeyen siteler için 8M, yükleme gereken siteler için 32M uygundur. upload_max_filesize de bunun altında kalmalı. Bu ayar CVE-2026-109618 için saldırı alanını daraltır.
• PHP 8.5’te fatal_error_backtraces=0 ayarlanır ve tüm worker’lar yeniden başlatılır.

Duyuruda bellek sınırıyla ilgili değişiklikler de anlatılıyor. Bunlar yanlarına sunucu seviyesinde bir bellek sınırı konmasını gerektirdiği için sunucuyu yöneten kişiye bırakılmalı. Bu adımların hiçbiri kurulumu güvenli hale getirmez. Dışarıya açık bir sunucu yamalanamıyorsa ve desteklenmeyen bir PHP sürümü çalıştırıyorsa, CERT-EU ve CISA yama yapılana kadar sunucunun çevrimdışı alınmasını öneriyor.

Yamadan sonra saldırı izlerine bakma

İstismar ayrıntıları düzeltme çıkmadan önce herkesin eline geçmişti. Bu yüzden bir süre yamasız kalan bir sitede, güncellemeden sonra hızlı bir kontrol yapmak gerekir. Aşağıdaki kontroller, kod çalıştırma saldırılarının en sık bıraktığı izleri yakalar.

• Tanımadığın hesaplar. Uygulamanın kullanıcı tablosunda ya da yönetim ekranında senin oluşturmadığın hesaplar aranır.
• Olmaması gereken PHP dosyaları. Yükleme ve önbellek klasörlerinde betik değil, veri bulunmalı. Yönettiğin sunucuda find /yukleme/klasoru -name "*.php" çalıştırılır ve sonucun boş çıkması beklenir.
• Dosya bütünlüğü. Canlıdaki kod git status ve git diff ile depoyla karşılaştırılır. Paketlenmiş yazılımlarda üreticinin yayımladığı checksum değerleri kullanılır.
• Loglar ve çökmeler. Web sunucusu ve PHP-FPM loglarında 20 ile 22 Ekim arasındaki olağan dışı isteklere, tekrarlayan worker çökmelerine ve bellek hatalarına bakılır.
• Yakın zamanda değişen dosyalar. find . -name "*.php" -mtime -3 son üç günde değişen PHP dosyalarını listeler. Kendi deploy’larının görünmesi normal, geri kalan her şey araştırılmalı.

Bir şey ters görünüyorsa önce PHP yamalanır. Ardından açığa maruz kalmadan önce alınmış temiz bir yedeğe dönülür, uygulama, veritabanı ve hosting kimlik bilgileri ile sunucuda duran API anahtarları yenilenir.

Bir sonraki açığa hazırlıklı olmak

PHP2Shell, uygulamanın altındaki katmanlarda çıkan son kritik açık olmayacak. Birkaç alışkanlık, bir sonrakini sıradan bir öğleden sonra işine çevirir.

• Desteklenen bir PHP dalında kal. Bu kez 8.1 ve daha eski dallar için resmi düzeltme çıkmadı. 8.2’nin güvenlik desteği 31 Aralık 2026’da bitiyor, 8.3 ise 31 Aralık 2027’ye kadar güvenlik düzeltmesi alıyor. Dalın bitmeden 8.3 ya da daha yeni bir sürüme geçişi planla.
• PHP’nin nereden geldiğini bil. Hosting firmasından mı, dağıtımdan mı, Ondřej Surý deposundan mı yoksa bir Docker imajından mı geldiğini not et. Yamayı kimin ve ne kadar hızlı yapacağını bu belirler. Yayın gününde yansılardaki gecikme ve Remi deposundaki boşluk bunu gösterdi.
• Doğru duyuruları takip et. Bu sürüm bir gün önceden haber verdi. PHP haber sayfası, framework’ünün güvenlik akışı ve hostingin durum sayfası bunu yakalamak için yeterli.
• Önce snapshot al, staging’de dene. Herhangi bir PHP değişikliğinden önce alınan snapshot ve sürüm yükseltmeleri için bir staging kopyası, kötü giden bir güncellemeyi beş dakikalık bir geri almaya çevirir.
• İşletim sistemi güvenlik güncellemelerini otomatikleştir. Ubuntu’da unattended-upgrades bunları uygulayabilir. Yine de PHP paket kaynağını kapsadığını doğrula, çünkü üçüncü taraf depolar varsayılan olarak dahil değildir.
• Diğer katmanları da güncel tut. Framework ve paket güncellemeleri PHP2Shell’i kapatmaz ama saldırganların yılın geri kalan günlerinde kullandığı açıkları kapatır. composer audit düzenli çalıştırılır ve bağımlılıklar güncel tutulur.
• Güvenlik duvarını çözüm değil, ek katman say. Cloudflare bu saldırılara karşı kural yayımladı. Yine de saldırganlar bazen CDN’i atlayıp kaynak sunucuya doğrudan ulaşabiliyor.
• Yedekleri sunucunun dışında tut ve geri yüklemeyi dene. Hiç geri yüklemediğin bir yedek plan değil, temenni olur.

Hepsinin özü basit. Sitenin altında ne çalıştığını, onu kimin yamaladığını bil ve bir sürümün yayımlanmasıyla senin güncellemen arasındaki süreyi kısalt.

Kaynaklar

• CERT-EU Security Advisory 2026-018, Critical Vulnerabilities in PHP
• Codeable, PHP Security Release on 21 October 2026
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching
• PHP 8.5.12 sürüm notları, GitHub
• Help Net Security, PHP2Shell critical PHP vulnerabilities patched
• ma.ttias.be, how to apply the PHP patches
• DreamFactory, PHP security advisory
• Brandefense, PHP2Shell fixed versions
• GoDaddy, Important PHP security update

Tüm projelerim ve üzerinde çalıştığım konuları incelemek istersen https://hub.barisgunduz.com/ adresini ziyaret edebilirsin.