PHP2Shell (CVE-2026-109618 ve CVE-2026-109619): Nedir ve Sunucularınızı Nasıl Yamanır ve Korursunuz

21 Ekim 2026 tarihinde PHP projesi, kimlik doğrulaması yapılmamış uzaktan kod çalıştırma (RCE) olanağı tanıyan iki kritik güvenlik açığı için acil güvenlik güncellemeleri yayınladı. Sorunlar PHP2Shell olarak adlandırıldı ve CVE-2026-109618 ve CVE-2026-109619 olarak takip edilmektedir. Her ikisi de CVSS v4.0 9.2 (Kritik) olarak derecelendirilmiştir.

watchTowr’daki güvenlik araştırmacıları, aktif istismar girişimleri gördüklerini bildiriyor ve Birleşik Krallık Ulusal Siber Güvenlik Merkezi (NCSC) bir uyarı yayınladı. Eğer WordPress, WooCommerce, Magento, Drupal, Laravel veya başka bir PHP uygulaması kullanıyorsanız, bunu acil bir durum olarak değerlendirin.

Bu kılavuz, nelerin etkilendiğini açıklar ve en yaygın kurulumları yamanmak için adım adım talimatlar verir. Ayrıca, bugün yamanamıyorsanız ne yapmanız gerektiğini ve bir sunucunun tehlikeye girip girmediğini nasıl kontrol edeceğinizi de kapsar.

Kısa versiyon: PHP’yi 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 (veya dağıtımınızın yamanmış paketini) güncelleyin, ardından her PHP işçisini yeniden başlatın. Sadece yapılandırma değişiklikleri bir sunucuyu güvenli hale getirmez.

PHP2Shell nedir?

PHP2Shell, PHP motorundaki iki ilgili bellek güvenliği hatası için verilen isimdir. Her ikisi de aynı sürümlerde düzeltilmiştir.

	CVE-2026-109618	CVE-2026-109619
PHP adı	OOM bozulması ile RCE	Eski küresel durum aracılığıyla RCE
Danışmanlık	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
Şiddet Derecesi	CVSS v4.0 9.2, Kritik	CVSS v4.0 9.2, Kritik
Yüksek düzeyde neden	Bellek yetersizliği yönetimi, PHP’yi kesintiye uğratabilirken, dahili istek verileri yalnızca kısmen başlatılmıştır ve istek temizliği bu geçersiz veriyi geçerli olarak değerlendirebilir.	Bir isteğe ait iç durum, belleği serbest bırakıldıktan sonra hayatta kalabilir ve aynı işçi tarafından işlenen sonraki bir istek bunu kullanabilir (serbest bırakıldıktan sonra kullanma).
Sonuç	Web sunucusu/işçi ayrıcalıkları ile olası uzaktan kod yürütme	Web sunucusu/işçi ayrıcalıkları ile olası uzaktan kod yürütme

Site sahipleri için önemli kısım: bu hatalar PHP’nin kendisinde bulunuyor, WordPress, Magento veya eklentilerde değil. PHP, saldırganın isteğini işler, bu nedenle tamamen güncellenmiş bir uygulama bile, altındaki PHP çalışma zamanı zayıfsa tehlikeye girmiş olur. PHP tavsiyesine göre, Apache mod_php üzerinde, kimlik doğrulaması yapılmamış bir isteğin, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetiklediği bir istismar gösterilmiştir.

Hangi sürümler etkileniyor?

PHP dalı	Açık	Düzeltilmiş durumda
8.5	8.5.12’den önce	8.5.12
8.4	8.4.27’den önce	8.4.27
8.3	8.3.36’dan önce	8.3.36
8.2	8.2.35’ten önce	8.2.35
8.1, 8.0, 7.4	Evet	Resmi bir sürüm yok. PHP güvenlik ekibinden veya satıcı/LTS geri taşımalarından minimal kaynak geri taşımaları.
Eski (7.3 ve altı, 5.x)	Varsayalım ki evet	Hayır düzeltme. Yükseltme

PHP 8.2’nin 31 Aralık 2026’da sonlanacağını unutmayın, bu nedenle yamanın ardından 8.4 veya 8.5’e yükseltme planlayın.

Hangi kurulumlar risk altında?

PHP danışmanlığına göre, web isteklerini karşılayan tüm PHP kurulumları risk altındadır. Bu şunları içerir:

mod_php ile Apache: en yüksek risk, uygulama öncesi bir istismar gösterilmiştir
PHP-FPM (Nginx, proxy_fcgi ile Apache, Caddy ve diğerleri)
php-cgi
FrankenPHP
LiteSpeed (LSAPI)

Paylaşımlı barındırma, yönetilen WordPress barındırma, VPS’ler, konteynerler ve Windows sunucuları, web istekleri için savunmasız bir PHP sürümü çalıştırıyorsa hepsi kapsam içindedir.

Adım 1: Her PHP kurulumunu bulun

Bilmediğiniz şeyi yamanız mümkün değildir. İnternete açık olanlardan başlayarak, PHP çalıştıran tüm sunucuların, konteynerlerin ve barındırma hesaplarının bir listesini yapın.

Komut satırında PHP sürümünü kontrol edin:

php -v

CLI sürümü, web sitenizi hizmet veren sürümden farklı olabilir. Ayrıca web sunucusunun PHP’sini kontrol edin:

PHP-FPM: php-fpm8.3 -v (Debian/Ubuntu isimlendirmesi), veya php-fpm -v
Yüklenmiş PHP paketlerini listele (Debian/Ubuntu): dpkg -l | grep -E '^ii\s+php'
Yüklenmiş PHP paketlerini listele (RHEL/Alma/Rocky): rpm -qa | grep -i php
WordPress’te: Araçlar → Site Sağlığı → Bilgi → Sunucu, sitenin kullandığı PHP sürümünü gösterir.
Magento’da: birden fazla PHP sürümünün genellikle yan yana kurulu olduğu için, barındırma sağlayıcınızla veya sunucuda kontrol edin

Staging sunucularını, eski test sitelerini, iç araçları, izleme panellerini ve unutulmuş alt alan adlarını unutmayın. Saldırganlar bunları da bulur.

Adım 2: PHP’yi Güncelle

Linux dağıtımları ve LTS satıcıları yamaları önceden aldı, bu nedenle yamanmış paketlerin mevcut olması veya yakında gelmesi gerekir. Düzeltmeyi içeren kesin paket sürümü için her zaman satıcınızın güvenlik izleyicisini kontrol edin. Dağıtım paketleri genellikle eski sürüm numarasını korur ve bir yama eki ekler. Örneğin, Ubuntu veya Debian, 8.3.36 demeyen düzeltme yapılmış bir “8.3.x” paketi gönderebilir. CVE kimlikleri için dağıtımınızın değişiklik günlüğünü veya güvenlik bildirimini kontrol edin.

Debian ve Ubuntu

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php*'

Yüklenen paketin değişiklik günlüğünde CVE-2026-109618 / CVE-2026-109619’ün geçtiğini onaylayın:

apt changelog php8.3-fpm | head -40

(php8.3-fpm yerine paket adınızı yazın.)

Eğer üçüncü taraf bir PHP deposu kullanıyorsanız (örneğin bir PPA veya Sury deposu), güncellenmiş paketler için o depoyu da kontrol edin.

RHEL, AlmaLinux, Rocky Linux, CentOS Stream

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'

Remi deposunu kullanıyorsanız (rpms.remirepo.net) önemli: PHP projesi, bu gönüllü tarafından bakım yapılan deponun yayın gününde güncellemeleri olmayacağını belirtmektedir. Hemen yamanız için dağıtım paketlerine geçmenizi veya kaynak koddan derlemenizi önerirler. O zamandan beri Remi’nin düzeltme paketleri yayınlayıp yayınlamadığını kontrol edin. Eğer yayınlamadıysa, beklemeyin.

Docker ve konteynerler

Host’u güncellemek PHP’yi konteynerler içinde düzeltmez. Görüntüleri yeniden oluşturmalısınız:

Temel resim etiketini yamanmış bir sürüme güncelleyin, örneğin php:8.3.36-fpm veya php:8.4.27-apache (veya düzeltme sürümüne işaret ettiğinde 8.x etiketini)
önbelleksiz yeniden inşa et böylece yeni temel çekilir:

docker build --pull --no-cache -t your-app:patched .

Her bir konteyneri yeniden dağıtın ve içindeki sürümü kontrol edin:

docker exec <container> php -v

Ayrıca, resmi WordPress, Nextcloud veya satıcı görüntüleri gibi kendiniz oluşturmadığınız görüntüleri de kontrol edin ve yamanmış sürümler yayınlanır yayınlanmaz güncelleyin.

Paylaşımlı ve yönetilen barındırma

Her bir site için PHP sürümünü kontrol etmek üzere hosting kontrol panelinizi (cPanel, Plesk, DirectAdmin) kontrol edin.
Hostunuza doğrudan CVE-2026-109618 ve CVE-2026-109619 için düzeltmelerin PHP derlemelerinde yer alıp almadığını ve ne zaman dağıtıldığını sorun.
Eğer siteniz PHP 8.1 veya daha eski bir sürümde çalışıyorsa, şimdi desteklenen bir sürüme geçin (mümkünse sahne ortamında test edin, ancak haftalarca geciktirmeyin).

cPanel/EasyApache, Plesk ve diğer paneller

Panel satıcıları kendi PHP sürümlerini gönderir. Panelin normal güncelleme sürecini çalıştırın ve yamanmış sürüm versiyonları için satıcının duyurusunu kontrol edin.

Windows

Resmi PHP indirme sayfasından yamanmış Windows sürümlerini indirin, PHP dizinini değiştirin (şu anki php.ini dosyanızı koruyun) ve IIS veya PHP hizmetini yeniden başlatın.

Kaynak kodundan derleme

php.net’ten 8.5.12, 8.4.27, 8.3.36 veya 8.2.35’i indirin. PHP 7.4, 8.0 ve 8.1 için PHP güvenlik ekibi, resmi danışmanlıktan bağlantılı minimal kaynak geri portlama dalları yayımlamıştır. Bunları yalnızca desteklenen bir sürüme geçici bir köprü olarak kullanın.

Adım 3: Her PHP işçisini yeniden başlatın

Bu, insanların unuttuğu adımdır. PHP-FPM havuzları, mod_php ile Apache ve diğer uzun süre çalışan PHP süreçleri eski kodu bellekte tutar, ta ki yeniden başlatılana kadar.

# PHP-FPM (Debian/Ubuntu, adjust the version)
sudo systemctl restart php8.3-fpm

# PHP-FPM (RHEL family)
sudo systemctl restart php-fpm

# Apache with mod_php
sudo systemctl restart apache2   # Debian/Ubuntu
sudo systemctl restart httpd     # RHEL family

# LiteSpeed
sudo systemctl restart lsws

Birden fazla PHP sürümünü yan yana çalıştırıyorsanız (örneğin php8.2-fpm ve php8.3-fpm), hepsini yamanız ve yeniden başlatmanız gerekir.

Adım 4: Doğrula

php -v komutunu çalıştırın ve FPM ikilisinin -v komutunu tekrar çalıştırın.
Geçici bir phpinfo() sayfası oluşturun, sürümü kontrol edin ve hemen silin
WordPress Site Health veya uygulamanızın sistem bilgileri bölümünde yeni sürümü onaylayın.
Konteynerlerde, her çalışan konteynerin içine bakın

Bugün yamanız mümkün değilse: geçici önlemler

PHP projesi çok net: sadece bir güncelleme tam bir çözümdür. Aşağıdaki önlemler belli saldırı yollarına maruziyeti azaltır. Bir sunucuyu güvenli hale getirmezler. Onları yalnızca saatler veya günler için bir köprü olarak kullanın, haftalar için değil.

Önce maruziyeti azaltın

İnternet erişimini kısıtlayın hemen yamanamadığınız PHP sistemlerine. Yönetici panelleri ve iç araçlar için bir VPN veya IP beyaz listeleme kullanın.
Önemli olmayan sistemler için, çevrimdışı hale getirmeyi düşünün çünkü acil düzeltme mümkün değilse, Birleşik Krallık NCSC bunu önermektedir.

CVE-2026-109618 (OOM bozulması)

Uygulamaların geçersiz kılamayacağı şekilde memory_limit=-1 ayarlayın, örneğin FPM havuzunda php_admin_value[memory_limit] = -1 veya Apache yapılandırmasında php_admin_value memory_limit -1 ile. Hiçbir havuz, dizin veya uygulama ayarının sonlu bir sınır koymadığından emin olun.
Bu, PHP’nin kendi bellek sınırını kaldırdığı için, güvenlik sınırı olarak bir kapsayıcı veya cgroup bellek limiti kullanın. Bunun için kullanmayın RLIMIT_AS veya RLIMIT_DATA. Danışmanlık, bunların savunmasız tahsis hatasına neden olabileceğini uyarıyor.
post_max_size değerini düşürün. Tavsiye, yükleme gerektirmeyen uygulamalar için 8M ve yüklemelerin gerekli olduğu durumlar için 32M önermektedir; upload_max_filesize değeri post_max_size değerinin altında olmalıdır.
Web sunucusu, proxy veya WAF seviyesinde, kullanılabilir bir Content-Length olmadan gelen istekler için bile, istek boyutu, alan sayısı, çok parçalı parça sayısı, başlık sayısı ve iç içe geçme sınırlarını zorlayın.

CVE-2026-109619 (eski küresel durum)

session.upload_progress.enabled=0 değerini php.ini, FPM havuzu veya sunucu yapılandırmasında (değil ini_set() veya .user.ini ile), ardından her işçiyi yeniden başlatın. Tavsiye, yükleme ilerlemesine ihtiyacınız yoksa, yamanmadan sonra bile bunu kapalı tutmanızı önerir.
PHP 8.5 üzerinde fatal_error_backtraces=0 ayarını yapın ve her işçiyi yeniden başlatın.
Geçersiz veya kullanım dışı olan, istek başlangıcından önce uyarılar üreten PHP ayarlarını kaldırın. Uyarıları display_errors veya error_reporting ile gizlemek yardımcı olmaz
Saldırganların tetikleyebileceği kritik hataları ve yürütme zaman aşımını düzeltin, örneğin yükleme veya içe aktarma işlemlerinde.

PHP-FPM havuz dosyası için örnek (/etc/php/8.3/fpm/pool.d/www.conf):

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off

Öncelikle sahnede test edin. -1 değerinde bir memory_limit ile eksik bir konteyner veya cgroup sınırının birleşimi, tek bir kontrolsüz script’in sunucunun tüm belleğini kullanmasına izin verebilir.

Adım 5: Kompromi işaretlerini kontrol et

Sömürü girişimlerinin zaten gözlemlendiği için, yamanın tek başına yeterli olmadığı internetten erişilebilir sunucular için. Büyük değişiklikler yapmadan önce, kanıtları koruyun: web sunucusu ve PHP günlüklerinin kopyaları, yapılandırma ve şüpheli dosyalar.

Sonra kontrol et:

Yeni veya değiştirilmiş PHP dosyaları, özellikle PHP’nin bulunmaması gereken yükleme klasörlerinde:

find /var/www -type f -name "*.php" -mtime -7
find /var/www -path "*/uploads/*" -name "*.php"

Web shell’leri: şifrelenmiş kod içeren küçük PHP dosyaları, eval, base64_decode, system, shell_exec veya assert alışılmadık yerlerde
Beklenmedik cron görevleri, özellikle web sunucusu kullanıcısı için:

sudo crontab -l -u www-data
ls -la /etc/cron.* /var/spool/cron/ 2>/dev/null

Yeni sistem veya uygulama hesapları: yeni WordPress veya Magento yönetici kullanıcıları, ~/.ssh/authorized_keys içinde yeni SSH anahtarları
Web sunucusu kullanıcısı olarak çalışan olağandışı süreçler veya dışa bağlantılar:

ps -u www-data -f
sudo ss -tunp | grep -E 'php|www-data|apache|nginx'

Web sunucu hataları ve çöküşleri: PHP-FPM işçi çöküşlerinde (segfault) veya günlüklerdeki bellek yetersizliği hatalarında bir artış, istismar girişimlerine işaret edebilir.

Eğer bir güvenlik ihlali belirtisi bulursanız, sunucuyu güvensiz olarak değerlendirin. Erişim sağladığı tüm kimlik bilgilerini (veritabanı, API anahtarları, SSH anahtarları, ödeme entegrasyonları) değiştirin ve temiz bir durumdan yeniden inşa etmeyi ve verileri bir yedekten geri yüklemeyi düşünün; bu yedek, ihlalden önce alınmış olmalıdır. Benim WordPress kötü amaçlı yazılım temizleme kılavuzum ve sunucu yedekleme stratejim bu adımları kapsamaktadır.

Hızlı kontrol listesi

Adım	Tamam mı?
Tüm PHP sunucularını, konteynerleri ve barındırma hesaplarını envanterleyin.
PHP’yi 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35’e veya yamanmış satıcı paketine güncelleyin.
Konteyner görüntülerini yeniden oluşturun ve yeniden dağıtın.
Tüm PHP-FPM havuzlarını, Apache’yi ve LiteSpeed’i yeniden başlatın.
Her sitedeki çalışan sürümü doğrulayın
Gerekmedikçe `session.upload_progress` özelliğini devre dışı bırakın
Yamanlanamayan sistemleri kısıtlayın veya izole edin.
Günlükleri, dosyaları, cron’u ve hesapları ihlal için kontrol et
PHP 8.2 ve daha eski sürümler için plan yükseltmesi

Gelecek için dersler

PHP2Shell, uygulama güncellemelerinin yeterli olmadığını hatırlatır. çalışma zamanı (PHP, web sunucusu, OS kütüphaneleri) aynı dikkati gerektirir:

PHP paketleri için güvenlik güncellemelerini otomatikleştirin, yeniden başlatma bekleniyorsa sizi uyaran bir izleme ile
Desteklenen PHP sürümlerinde kalın
Envanterinizi bilin: hangi siteler hangi PHP sürümünü nerede çalıştırıyor
Test edilmiş, dışarıda yedeklemeleri koruyun
Yeni kurulumlar için mod_php yerine PHP-FPM’i tercih edin, her site için ayrı havuzlar ve kullanıcılar ile

Benim Linux sunucu güvenliğini artırma kontrol listem bu rutini nasıl oluşturacağınızı açıklar.

Sıkça sorulan sorular

WordPress (veya Magento, Laravel, Drupal) PHP2Shell’e karşı savunmasız mı?

Güvenlik açıkları PHP’nin kendisindedir, uygulamalarda değil. Güvenli bir PHP sürümünde çalışmayan bu uygulamalardan herhangi biri, PHP aracılığıyla tehlikeye atılmıştır. WordPress veya eklentileri güncellemek bunu düzeltmez. PHP’yi güncellemeniz gerekir.

PHP’yi güncelledim. Neden sitem hala eski sürümü gösteriyor?

PHP-FPM veya Apache süreci yeniden başlatılmamış, ya da site güncellediğinizden farklı bir PHP sürümü veya havuzu kullanıyor. Tüm PHP hizmetlerini yeniden başlatın ve her siteyi kontrol edin.

php.ini’yi değiştirmek yeterli mi?

Hayır. PHP projesi, yapılandırma değişikliklerinin belirli saldırı yollarına maruziyeti azalttığını ancak bir kurulumun güvenli hale gelmesini sağlamadığını belirtmektedir. Güncelle.

Sunucum PHP 7.4 veya 8.1 çalıştırıyor. Şimdi ne yapmalıyım?

Bu sürümler artık resmi PHP sürümleri almıyor. İşletim sistemi sağlayıcınızın veya bir LTS sağlayıcısının geri port edilmiş bir düzeltme sunup sunmadığını kontrol edin. PHP projesi 7.4, 8.0 ve 8.1 için minimal kaynak geri portları yayınladı. Gerçek çözüm, mümkün olan en kısa sürede desteklenen bir sürüme (8.4 veya 8.5) yükseltmektir.

Bir WAF beni korur mu?

Bir web uygulama güvenlik duvarı, bazı bilinen saldırı desenlerini engelleyebilir ve istek sınırlarını uygulayarak riski azaltır. Yamanın yerini almaz.

Paylaşımlı barındırmam güvenli mi?

Sadece eğer barındırıcınız yamanmış PHP sürümlerini dağıttıysa ve PHP işçilerini yeniden başlattıysa. Onlara doğrudan sorun ve yazılı bir onay alın.

Sunucularınızı yamanıza mı yardımcı olmamız gerekiyor?

Ben işletmelere WordPress, WooCommerce, Magento ve özel uygulamalar çalıştıran PHP sunucularının envanterini çıkarmalarına, yamanmalarına ve güvenli hale getirmelerine yardımcı oluyorum; bu, konteyner yeniden yapılandırmaları ve güvenlik kontrollerini de içerir. sunucular ve yedekleme hizmetim veya acil yardım talep et kısmına bakın.