PHP2Shell Açığı: Etkilenen PHP Sürümleri ve Güvenlik Yaması

PHP2Shell, PHP'nin istek işleme mekanizmasındaki iki kritik güvenlik açığına verilen ortak ad: CVE-2026-109618 ve CVE-2026-109619. Başarılı bir saldırı, oturum açılmadan sunucuda kod çalıştırılmasına yol açabiliyor. Her iki açığın PHP tarafından verilen CVSS v4.0 puanı 9,2. Konu yalnızca belirli bir eklentiyi veya içerik yönetim sistemini ilgilendirmiyor; güncellenmesi gereken bileşen PHP çalışma zamanı. Teknik kayıtlar PHP projesinin ilk ve ikinci güvenlik bildiriminde bulunuyor.

Sunucuyu yönetiyorsan ilk işin hangi alan adının hangi PHP çalıştırıcısını kullandığını belirlemek olmalı. Hosting müşterisiysen sağlayıcından kullandığın PHP paketinin bu iki CVE için yamalandığını doğrulamasını iste. Yönetim panelinde yalnızca “PHP 8.3” yazması, güvenlik güncellemesinin uygulanıp uygulanmadığını söylemez.

PHP2Shell hangi siteleri etkiliyor?

Açıklar PHP'nin içinde. WordPress, Drupal ve Joomla üzerinde gösterilmiş olmaları, kapsamın bu uygulamalarla sınırlı olduğu anlamına gelmiyor. Kendi yazdığın PHP uygulaması da aynı çalışma zamanını kullanıyor. Araştırmacıların açıklaması, uygulamaya özel bir kod hatasının gerekmediğini ve PHP süreç belleğinden hassas veri okunmasının da gösterildiğini belirtiyor.

PHP'nin resmî duyurusu; PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil web isteği karşılayan kurulumları risk kapsamında değerlendiriyor. Mod_php için uygulama kodu çalışmadan önce tetiklenebilen saldırı doğrulanmış durumda. “Nginx kullanıyorum” veya “sitemde dosya yükleme formu yok” diyerek incelemeyi kapatmak doğru değil.

Kod çalıştırma, ilk aşamada web işçisinin yetkileriyle gerçekleşir; otomatik olarak root erişimi demek değildir. Yine de o hesabın okuyabildiği uygulama ayarları, veritabanı parolaları ve yazabildiği dosyalar açısından ciddi bir etki yaratabilir. Risk değerlendirmesinde hesabın gerçek dosya izinlerini ve ağ erişimini de hesaba kat.

İki açıkta ne bozuluyor?

CVE-2026-109618, bellek yetersizliği sırasında yarıda kesilen işlemlerle ilgili. PHP bazı iç istek yapılarını hazırlarken bir bellek hatası oluştuğunda, temizleme aşaması henüz geçerli duruma gelmemiş veriyi kullanabiliyor. Bu, yalnızca “çok bellek tüketip siteyi yavaşlatmak” şeklinde ele alınacak bir kaynak tüketimi sorunu değil; bellek güvenliği ihlali. CVE-2026-109618 teknik kaydı doğrulanmış etkiyi açıklıyor.

CVE-2026-109619 ise istek bittikten sonra geride kalan geçersiz iç durumla ilişkili. Serbest bırakılmış belleğe işaret eden durum, aynı işçinin sonraki isteğinde yeniden kullanılabiliyor. Buna use-after-free, yani serbest bırakılmış belleğin kullanılması deniyor. İlgili bildirim, oturum yaşam döngüsü üzerinden mod_php ve FPM üzerinde kod çalıştırmanın doğrulandığını belirtiyor. Dolayısıyla farklı çalıştırıcılar ve ayarlar, saldırı koşullarını değiştirse de FPM kullanmak tek başına çözüm sayılmıyor.

Hangi PHP sürümüne geçilmeli?

PHP projesinin bu açıkları düzelten ilk sürümleri aşağıda. Aynı dalın daha yeni bir güvenlik sürümü varsa onu tercih et. Listeyi, dağıtımının paket sürümüyle birebir sayısal karşılaştırma yaparak kullanma; dağıtım yamaları ayrı değerlendirilir. Düzeltmeler PHP değişiklik kayıtlarında da yer alıyor.

PHP 8.1 ve daha eski dallar PHP projesinin normal desteği dışında. Bununla birlikte dağıtım veya uzun süreli destek sağlayıcısı eski bir dala güvenlik yamasını taşıyabilir. PHP ekibi 7.4, 8.0 ve 8.1 için kaynak düzeyinde asgari backport değişikliklerini de paylaştı; bu, bu dalların yeniden desteklenen sürümler olduğu anlamına gelmiyor. Paket sağlayıcının ilgili CVE'leri kapattığını doğrula; doğrulanmış yama yoksa desteklenen bir dala geçişi veya internet erişimini sınırlandırmayı planla.

Önce gerçekten kullanılan PHP'yi bul

Terminalde gördüğün PHP ile web sitesinin kullandığı PHP farklı olabilir. Bir sunucuda varsayılan CLI, birden fazla FPM servisi ve panelin kendi PHP'si aynı anda bulunabilir. İlk envanter için:

command -v php
php -v
php --ini
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp'
systemctl list-units --type=service --all | grep -Ei 'php.*fpm|apache2|httpd|lsws'

php --ini, komut satırında çağrılan PHP'nin yapılandırmasını gösterir. Web çalıştırıcısının aynı dosyayı okuduğunu varsayma. PHP yapılandırma dokümanı, yükleme yerlerinin çalıştırıcıya göre değişebildiğini açıklıyor. Sunucu yalnızca konteynerlerden oluşuyorsa systemd listesi de tek başına tüm envanteri vermez.

Web sürümünü doğrulamak için erişimi sunucu veya proxy düzeyinde yalnızca yöneticiye açık geçici bir tanı rotasında şu kısa çıktı kullanılabilir:

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP: ', PHP_VERSION, PHP_EOL;
echo 'SAPI: ', PHP_SAPI, PHP_EOL;

Bu kod erişim kontrolü sağlamaz; kısıtlamayı rotayı açmadan önce yap. fpm-fcgi, apache2handler veya litespeed gibi değerler, hangi çalıştırıcıyı inceleyeceğini gösterir. Kontrol bitince tanı rotasını kaldır. SAPI bilgisi ile sürümü birlikte kaydet; yalnızca sitenin açılması, doğru PHP işçisinin yenilendiğinin kanıtı değildir.

Ubuntu ve Debian'da paket yamasını doğrula

Backport, güvenlik düzeltmesinin eski bir sürüm tabanına uygulanmasıdır. Örneğin Ubuntu 24.04 için 8.3.6-0ubuntu0.24.04.13, Ubuntu 22.04 için 8.1.2-1ubuntu2.28 paketleri bu açıkları düzeltiyor. Sadece ilk üç sayıya bakıp bu paketleri savunmasız ilan etmek hatalı olur. Tam paket sürümünü USN-8948-1 ile karşılaştır.

dpkg-query -W -f='${Package} ${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
apt-cache policy php8.3-common php8.3-fpm php8.3-cli

İkinci satır Ubuntu 24.04 üzerinde dağıtımın PHP 8.3 paketlerini kullanan bir kurulum için örnektir. Başka dal veya depo kullanıyorsan paket adlarını ona göre değiştir. Kurulu sürüm ile aday sürüm farklıysa güncelleme henüz uygulanmamış olabilir; depo kökenini de kontrol et.

Ubuntu, paket dizinini yenileyip sistem güncellemelerini uygulamayı öneriyor. Aşağıdaki komutlar sistemi değiştirir; gösterilecek paket listesini incele:

sudo apt update
sudo apt upgrade

Paketlerin diskte yenilenmesi, bellekte çalışan tüm işçilerin değiştiği anlamına gelmez. FPM kullanıyorsan ilgili servisi; mod_php kullanıyorsan Apache'yi yeniden başlat. Örneğin PHP 8.3 FPM için sudo systemctl restart php8.3-fpm, mod_php için sudo systemctl restart apache2. Hizmet kesintisini hesaba kat. Bu ayrıntı Ubuntu'nun açıklamasında da vurgulanıyor.

Debian 13 için 8.4.27-1~deb13u1 sürümü DSA-6574-1 kapsamında yayımlandı. Debian 12 için 8.2.35-1~deb12u1 paketi de güvenlik deposuna kabul edildi. Kullandığın deponun güncel durumunu esas al; bir duyurunun eski önbellek kopyası, sonraki paket dağıtımını yansıtmayabilir.

cPanel sunucusunda web PHP'si ve panel PHP'si ayrı

cPanel tarafında iki katmanı kontrol et: sitelerin kullandığı EasyApache PHP paketleri ve cPanel/WHM arayüzlerinin kullandığı iç PHP. cPanel sürüm notları, iç PHP düzeltmesinin Roundcube dahil panel arayüzlerini kapsadığını belirtiyor. Yalnızca sitenin PHP dalını değiştirmek, panel bileşenlerinin de güncellendiğini göstermez.

cPanel'in güvenlik duyurusunda düzeltilmiş panel sürümleri 110.0.153, 134.0.66, 136.0.50 ve 138.0.18 olarak listeleniyor. EasyApache tarafında desteklenen yeni dallar upstream düzeltmelerini; 7.4, 8.0 ve 8.1 paketleri ise backport yamalarını alıyor. Paket revizyonunu kontrol et.

/usr/local/cpanel/cpanel -V
rpm -qa | grep -E '^(ea-php|alt-php)'

RPM komutu AlmaLinux/Rocky/CloudLinux gibi RPM tabanlı kurulumlar içindir. Kullanılmayan bir PHP paketini güncellemekle yetinme; MultiPHP Manager veya sağlayıcının eşdeğer ekranında her alan adının etkin çalıştırıcısını belirle. CloudLinux'ta ea-php ve alt-php paket ailelerini birbirine karıştırma. İkinci aile için sağlayıcının kendi paket duyurusunu kontrol et.

WHM'nin güncelleme akışını ve EasyApache paket güncellemelerini tamamla. Sonrasında her etkin PHP dalının işçilerini üreticinin yeniden başlatma yöntemiyle yenile; panel servislerinin durumunu da doğrula. Hosting müşterisinin yapacağı iş ise sağlayıcıdan hem web çalıştırıcısı hem panel tarafı için yama teyidi almak.

Konteyner ve Windows kurulumlarını da envantere kat

Bir PHP konteyneri kullanıyorsan host işletim sisteminin PHP paketlerini güncellemek konteyneri değiştirmez. Kullanılan imajın içindeki PHP'yi kontrol et; düzeltilmiş taban imajla yeniden oluşturup çalışan örnekleri yenile. Etiketin aynı kalabilmesi nedeniyle dağıtıma aldığın imaj özetini de kaydet. Tek örneği yenileyip diğer replikanın eski imajda kalmadığını kontrol et.

Windows/IIS tarafında da PATH üzerindeki php.exe ile FastCGI eşlemesinin gösterdiği dosya farklı olabilir. IIS işleyici eşlemesini ve FastCGI uygulama yolunu incele. Yama uygulanırken mimariyi, TS/NTS seçimini ve uzantı uyumluluğunu koru; ardından ilgili uygulama havuzunu yenileyip sürümü web üzerinden doğrula. Panelin yönettiği PHP için o panelin paketini kullan; farklı sağlayıcının dosyalarını aynı dizinde karıştırma.

Güncelleme gecikiyorsa hangi önlem ne kadar işe yarar?

PHP ekibinin geçici önerileri belirli saldırı yollarını daraltıyor; tam düzeltme sağlamıyor. session.upload_progress.enabled=0, erken yüklenen sunucu/FPM yapılandırmasında uygulanıp bütün işçiler yeniden başlatıldığında doğrulanmış oturum yolunu sınırlandırıyor. Uygulamadaki ini_set() çağrısı veya FPM .user.ini dosyası bu amaç için yeterli değil.

Duyuruda geçen memory_limit=-1 de genel bir hızlandırma önerisi değil. PHP bellek sınırını kaldırdığı için kaynak tüketimi riskini artırabilir; alttaki bellek ayırma hatalarını da ortadan kaldırmaz. Bir satırlık “kesin çözüm” olarak uygulama. Yamayı geciktirmek yerine, gerekiyorsa etkilenen uygulamanın kamuya açık erişimini geçici olarak sınırlandır.

Cloudflare, PHP2Shell korumalarını ve gözlemlediği saldırı trafiğini açıkladı; PHP güncellemesini yine de öneriyor. WAF olay kaydı, her isteğin engellendiğini veya sunucunun hiç etkilenmediğini kanıtlamaz. Doğrudan origin erişimi gibi koruma katmanını atlayan yolları da denetle. Saldırı isteği görülmesiyle başarılı kod çalıştırma bulgusunu birbirinden ayır.

Yamadan sonra neyi kontrol etmeli?

Güncelleme, daha önce bırakılmış bir dosyayı veya çalınmış parolayı geri almaz. İnceleme başlangıcı olarak PHP bellek hatalarını, işçi çökmelerini, beklenmedik dosya değişikliklerini ve web hesabından başlayan sıra dışı süreçleri birlikte değerlendir. Tek başına bir bellek hatası saldırı kanıtı değildir; bu kayıtların bulunmaması da temiz raporu vermek için yeterli olmaz.

# PHP 8.3 FPM örneği; kendi servis adını kullan.
sudo systemctl is-active php8.3-fpm
sudo journalctl -u php8.3-fpm --since '24 hours ago' --no-pager
# Apache mod_php kullanılıyorsa ilgili apache2/httpd günlüğünü incele.

Şüpheli bir dosya veya süreç bulursan önce erişimi sınırlandırıp günlükleri ve gerekli kanıtları koru. Kanıtı silerek temizlik yapma. Uygulama sırlarının erişilmiş olabileceği bir olayda, temiz sistem üzerinden parola ve anahtar yenilemeyi de olay müdahalesine dahil et.

İşi kapatmadan önce şu dört bilgiyi aynı kayıt üzerinde eşleştir: alan adı veya servis, gerçekten çalışan PHP yolu/SAPI, kurulu paketin iki CVE'yi düzelttiğini gösteren üretici kaydı ve yenilenmiş işçiden alınan web sürümü. Ardından giriş, dosya yükleme ve ödeme gibi kullandığın temel akışları dene; geçici tanı rotasını kaldır.