PHP2Shell: her PHP sunucusunu bulma, yamalama ve doğrulama komutları

PHP2Shell, doğrudan PHP motorunun kendisinde bulunan iki kritik güvenlik açığının adıdır: CVE-2026-109618 ve CVE-2026-109619. Açıklar 21 Ekim 2026’da CVSS 9.2 önem derecesiyle yayımlandı. Yaması yapılmamış bir çalışma ortamında, hesabı olmayan bir saldırgan PHP worker süreci olarak kod çalıştırabilir ya da parolaları, oturum token’larını, API anahtarlarını ve sertifikaları tutan süreç belleğini okuyabilir. Bunun için uygulama kodunuzda bir hata olması gerekmez: araştırmacılara göre etkilenen bir PHP sürümündeki basit bir “Hello World” sayfası bile açıkta kalabilir. Tek gerçek çözüm, düzeltilmiş bir PHP sürümüne geçmek ve ardından PHP çalıştıran her süreci yeniden başlatmaktır. Bu rehber size gereken komutları veriyor.

Hangi sürümler düzeltildi

PHP 8.1, 8.0 ve 7.x’in desteği sona erdi ve bu sürümler için düzeltme yayımlanmayacak. Hâlâ bunları kullanıyorsanız yama, desteklenen bir dala geçmek anlamına gelir.

Linux dağıtımları güvenlik düzeltmelerini çoğu zaman upstream sürüm numarasına geçmeden kendi paketlerine geri taşır (backport). Bu sistemlerde sürüm numarası tek başına yeterli bilgi vermez: paketin değişiklik günlüğünde (changelog) iki CVE numarasını arayın (Adım 2).

Adım 1: her PHP çalışma ortamını bulun

Envanterle başlayın, çünkü saldırıya uğrayan genellikle kimsenin hatırlamadığı çalışma ortamıdır. Her sunucuda:

php -v
systemctl list-units --type=service --all 'php*' 'apache2*' 'httpd*'
ls /usr/sbin/php-fpm* /usr/bin/php[0-9]* 2>/dev/null

İlk satır CLI sürümünü, ikincisi çalışan PHP-FPM havuzlarını ve web sunucularını, üçüncüsü ise yan yana kurulu bütün PHP sürümlerini gösterir (unutulan çalışma ortamlarının yaygın bir kaynağı). Kurulu paketleri de listeleyin:

dpkg -l 'php*' | grep '^ii'      # Debian, Ubuntu
rpm -qa 'php*' 'ea-php*'         # RHEL, AlmaLinux, Rocky, cPanel

Konteynerler için çalışan her imajın içindeki PHP sürümünü kontrol edin:

docker ps --format '{{.Names}}' | while read c; do printf '%s: ' "$c"; docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'; done

Test (staging), cron ve kuyruk sunucularını, derleme ajanlarını ve yönetilen barındırma paketlerini unutmayın. Barındırma paketi kullanıyorsanız sağlayıcınıza hangi PHP derlemesini kullandığınızı ve bunun ne zaman yamalandığını yazılı olarak sorun.

Adım 2: düzeltilmiş sürümü kurun

Debian ve Ubuntu (8.3 yerine kendi dalınızı yazın):

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

RHEL, AlmaLinux, Rocky Linux:

sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

EasyApache 4 paketleri kullanan cPanel sunucuları:

sudo dnf upgrade 'ea-php*'      # older systems: sudo yum update 'ea-php*'

Alpine Linux (paket adları dalı içerir, örneğin php83):

apk update && apk upgrade 'php83*'

Docker imajları: Dockerfile içinde düzeltilmiş etiketi sabitleyin, örneğin FROM php:8.3.36-fpm; ardından imajı önbellek kullanmadan yeniden derleyin ve çalışan konteynerleri değiştirin:

docker build --pull --no-cache -t myapp:php2shell .
docker compose up -d --build --force-recreate

Changelog üzerindeki grep hiçbir şey yazdırmıyorsa dağıtımınız düzeltmeyi henüz yayımlamamıştır. Kontrol etmeye devam edin, PHP’yi kendiniz derlediğiniz yerlerde php.net üzerindeki resmî sürümü kullanın ve bu arada aşağıdaki geçici önlemleri uygulayın.

Adım 3: eski PHP’yi yüklemiş her şeyi yeniden başlatın

Yeni bir paket, zaten çalışmakta olan süreçlerde hiçbir şeyi değiştirmez. Bu süreçleri yeniden başlatın:

sudo systemctl restart php8.3-fpm     # Debian, Ubuntu (one per installed version)
sudo systemctl restart php-fpm        # RHEL family
sudo systemctl restart apache2        # Apache with mod_php (httpd on RHEL)
sudo supervisorctl restart all        # long-running workers under Supervisor
php artisan queue:restart             # Laravel queue workers

Debian ve Ubuntu’da sudo needrestart -r l, hâlâ eski kütüphaneleri kullanan servisleri listeler.

Adım 4: doğrulayın

Her çalışma ortamını yeniden kontrol edin; bu kez yalnızca CLI’yi değil, web sunucusunun kullandığı ortamı da:

php-fpm8.3 -v                         # or: php-fpm -v
systemctl status php8.3-fpm | grep Active

Sürüm, düzeltilmiş sürüme eşit ya da ondan yüksek olmalı (veya paket changelog’u iki CVE’yi de listelemeli) ve “Active: since” zamanı güncellemeden sonra olmalıdır. WordPress’te sürümü Araçlar, Site sağlığı, Bilgi, Sunucu altında da görebilirsiniz. Kontrol etmek için internete bir phpinfo() sayfası koymayın: bu sayfa saldırganların aradığı bilgileri tam olarak ortaya serer.

Güncellemenin beklemesi gerekiyorsa

Araştırmacıların önerdiği bu ayarlar, siz güncellemeyi hazırlarken maruziyeti azaltır. Bunlar bir düzeltme değildir:

; php.ini
post_max_size = 8M                  ; as low as your uploads allow
max_input_nesting_level = 32        ; as low as your forms allow
session.upload_progress.enabled = 0
fatal_error_backtraces = 0          ; where your PHP version supports it

; PHP-FPM pool: recycle workers more often (costs performance)
pm.max_requests = 100

Değerler örnektir; bunları uygulamanızla test edin. memory_limit = -1 ayarı bazı saldırı yollarını engeller, ancak bunu yalnızca cgroup v2 memory.max gibi bir işletim sistemi sınırıyla birlikte kullanın ve bu sınırın yerine asla RLIMIT_AS ya da RLIMIT_DATA kullanmayın. Sağlayıcınızın WAF ve CDN kuralları geçiş dönemi için yardımcı olur, ancak güncellemenin yerini tutmaz.

Saldırı belirtilerini arayın

Tek bir tespit kuralı yoktur. Bu komutlar, araştırmacıların tarif ettiği sinyalleri ortaya çıkarır:

grep -E 'Allowed memory size of [0-9]+ bytes exhausted' /var/log/php*-fpm.log /var/log/apache2/error.log
grep -E 'exited on signal (6|11)' /var/log/php*-fpm.log
awk '$9 == 500' /var/log/nginx/access.log | wc -l

Olağandışı multipart isteklerinin ardından gelen bellek sınırı hataları, HTTP 500 yanıtlarındaki ani artışlar, sinyal alarak çöken PHP worker’ları ve yanıtlardaki alışılmadık büyüklükte PHPSESSID çerezleri daha yakından incelenmeyi hak eder. Bunların hiçbiri bir saldırıyı kanıtlamaz; yoklukları da etkilenmediğinizi kanıtlamaz. Bu belirtileri bulursanız günlükleri saklayın, yamayı uygulayın ve PHP belleğinde bulunan gizli bilgileri yenileyin: veritabanı parolaları, uygulama anahtarları ve API token’ları. Olay müdahale ekibimiz incelemeyi devralabilir, yönetilen güvenlik hizmetimiz de yamadan sonra sunucularınızı izleyebilir.

Nereden başlamalı

1. Envanter komutlarını her sunucuda ve konteynerde çalıştırın ve her PHP sürümünü listeleyin.
2. Paket yöneticinizle güncelleyin ya da imajlarınızı düzeltilmiş bir etiketle yeniden derleyin.
3. PHP-FPM’i, Apache’yi ve her PHP worker’ını yeniden başlatın.
4. Sürümü ve yeniden başlatma zamanını doğrulayın, çıktıyı kanıt olarak saklayın.
5. Günlüklerinizde yukarıdaki belirtileri grep ile arayın ve bunları gösteren her sistemde gizli bilgileri yenileyin.

Ayrıntılar: PHP2Shell duyuru sitesi, PHP Foundation duyurusu, Wiz Research.