php2shell (CVE-2026-109618 / 109619) php -v ile değerlendirilemez: FPM, Docker ve dağıtımlarda sürüm numaraları nerede birbirinden ayrışıyor

Web isteklerini işleyen PHP (PHP-FPM, Apache'nin mod_php'si, php-cgi, FrankenPHP, LiteSpeed) 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sürümlerinden eskiyse, php2shell olarak bilinen CVE-2026-109618 ve CVE-2026-109619'dan etkilenir. Çözüm, bu sürümlerden birine (dağıtım paketlerinde düzeltilmiş pakete) yükseltmek ve süreçleri yeniden başlatmaktır. Kontrol etmeniz gereken yerel php -v çıktısı değil, “web'e fiilen hizmet veren PHP” ve “kurulu paket sürümü”dür.

Bu yazı, yalnızca sürüm numarasına bakarak karar vermenin yanlış sonuca götürdüğü dört noktaya odaklanır. Tüm rakamlar ve durum bilgileri 2026-10-22 itibarıyladır; her maddenin kaynakları yazının sonunda listelenmiştir.

2026-10-22 itibarıyla bilinenler

PHP duyurusu “tek eksiksiz çözümün güncelleme olduğunu” belirtiyor. Güncelleme yapabilene kadarki dönem için önlemler yazının ilerleyen bölümünde ele alınıyor.

Tuzak 1: php -v ile web'e bakan PHP farklı olabilir

SSH üzerinden yazdığınız php -v, CLI PHP'nin sürümünü bildirir. Web isteklerini PHP-FPM süreçleri veya Apache'ye yüklenmiş mod_php işler; bunlar ayrı çalıştırılabilir dosyalar ve ayrı paketlerdir. PHP'nin yeni sürümünü yalnızca CLI için kurduysanız, yan yana birden çok sürüm çalıştırıyorsanız veya bir FPM havuzu farklı bir sürümü gösteriyorsa, php -v düzeltilmiş sürüm gösterse bile web tarafı eski kalabilir.

Web tarafındaki gerçek sürümü görmenin birkaç yolu var.

# Debian / Ubuntu'da FPM (adı sürüme göre verilir)
php-fpm8.3 -v

# RHEL ailesinde FPM
php-fpm -v

# mod_php'nin Apache'de yüklü olup olmadığını kontrol et
apachectl -M | grep -i php

En güvenilir yöntem, web üzerinden gerçekten çalışan PHP'nin kendi sürümünü bildirmesini sağlamaktır. Tahmin edilmesi zor bir adla geçici bir dosya koyun ve kontrol ettikten hemen sonra silin.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

PHP_SAPI değeri fpm-fcgi ise PHP, FPM altında çalışıyordur; apache2handler mod_php, cgi-fcgi ise CGI demektir. phpinfo() çıktısını açık bırakmaktan kaçının; bu başlı başına bilgi sızdırır.

Yeniden başlatma da kolay gözden kaçan bir adımdır. Paket değiştirilse bile zaten çalışan php-fpm veya Apache süreçleri eski kodu çalıştırmaya devam edebilir. Bazı kurulumlar paket güncellemesinde otomatik yeniden başlar, bazıları başlamaz. Güncellemeden sonra FPM / Apache'yi yeniden başlatın ve web tarafındaki sürümü yukarıdaki yöntemlerle yeniden kontrol edin.

Tuzak 2: Docker'da etiket adına bakarak karar veremezsiniz

Resmî php imajında, içeriği değiştirilen 8.3 ve 8.3-fpm gibi “kayan etiketler” ile sürümü sabitleyen 8.3.30 gibi sabitlenmiş etiketler vardır.

• Bir kayan etiket Docker Hub'da düzeltilmiş sürüme geçirilse bile, yerel kopyanız yeniden pull edene kadar eski imaj olarak kalır. Çalışan konteynerler de yeniden oluşturulana kadar eski imajı kullanır. FROM php:8.3-fpm içeren bir Dockerfile, derleme önbelleğinde eski taban imaj duruyorsa yine eski tabanla derlenir.
• Bir sabitlenmiş etiket, numarayı kendiniz yükseltene kadar sonsuza dek eski kalır.

Düzeltilmiş sürüm etiketlerinin yayımlanıp yayımlanmadığını Docker Hub API'siyle kontrol edebilirsiniz.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Dört sürüm hattı için 2026-10-22'de yapılan sorgunun sonuçları aşağıdadır (saatler UTC).

Bu kontrol sırasında, sayılara bakarak karar vermenin yanıltabileceği üç nokta ortaya çıktı.

1. “Yakın zamanda güncellendi” ifadesi “düzeltildi” anlamına gelmez. Sabitlenmiş 8.3.35 etiketi 2026-10-21 içinde yeniden derlenmişti, ancak içindeki PHP_VERSION hâlâ 8.3.35'ti. Güncellenme zamanına değil, içindeki sürüme bakın.
2. Digest'ler farklı olsa da içerik aynı olabilir. 8.3 ile 8.3.36 etiketlerinin digest'leri (çoklu mimari dizininin değeri) farklıydı, ancak amd64 imajı aynıydı ve ikisinde de PHP_VERSION=8.3.36 idi. Aynı şekilde 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm ve 8.2-fpm için de amd64 imajının PHP_VERSION değeri düzeltilmiş bir sürümdü.
3. 8.1 ve öncesi için düzeltilmiş resmî imaj yok. 8.1-fpm en son 2025-12-31'de güncellendi.

Yerel imajlarınızı ve çalışan konteynerlerinizi kontrol etmek için:

# Yerelde pull edilmiş bir imajın PHP sürümü
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Yeniden pull edin ve konteynerleri yeniden oluşturun
docker compose pull
docker compose up -d

# Kendi imajınızı derliyorsanız, tabanı yeniden pull edip sonra derleyin
docker compose build --pull

# Çalışan bir konteynerin içindeki sürüm
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Son komuttaki app yerine kendi servis adınızı yazın. Her resmî imaj tek bir PHP_VERSION ile derlenir; dolayısıyla konteynerin içindeki CLI sürümü, o konteynerin FPM / Apache sürümüyle aynıdır (Tuzak 1, PHP doğrudan ana makineye kurulduğunda geçerlidir).

FrankenPHP, PHP'yi içine gömer; bu nedenle FrankenPHP sürümü ile gömülü PHP sürümü farklı numaralardır. 2026-10-21'de yayımlanan FrankenPHP 1.13.2'nin sürüm notlarında, Docker imajlarının PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 ile, statik ikili dosyaların ise PHP 8.5.12 ile derlendiği belirtiliyor.

Tuzak 3: Dağıtım paketleri “eski numarayla düzeltilmiş” olur

Ubuntu ve RHEL, yalnızca düzeltmeleri eski sürümlere taşır (backport). php -v çıktısındaki numara eski kalır; bu yüzden “8.3.36'dan düşük, dolayısıyla savunmasız” biçimindeki sayısal bir kontrol, düzeltilmiş bir sistemi de savunmasız olarak işaretler. Tersine, numaraya bakıp rahatlamak da mümkün değildir. Kararı paket sürümüne ve her dağıtımın güvenlik takipçisine göre verin.

2026-10-22 itibarıyla her takipçide listelenen düzeltilmiş paketler (iki CVE için de aynı):

Bu tablo, numaranın neden tek başına yetmediğini doğrudan gösteriyor. Ubuntu 24.04'ün düzeltilmiş PHP'si 8.3.6 ile başlayan bir sürümdür ve upstream'in 8.3.36'sından çok düşüktür. RHEL 9'un varsayılan PHP'si, upstream artık 8.0 için düzeltme yayımlamadığı hâlde 8.0.30'da kalarak düzeltilmiştir. Debian ise upstream ile aynı numaralara (8.2.35 / 8.4.27) geçmiştir.

Bazı paketler henüz düzeltilmedi (2026-10-22 itibarıyla).

• RHEL 9 php modülü 8.4, “etkileniyor, düzeltme yok” olarak listelenmiştir.
• Debian forky'de (testing) php8.4 8.4.26-1 olup “vulnerable” olarak işaretlenmiştir. sid'deki (unstable) php8.4 8.4.27-1'dir ve düzeltilmiştir.

Kendi sunucunuzu kontrol etmek için örnek komutlar:

# Debian / Ubuntu: kurulu sürüm ve edinilebilir sürüm
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: bu CVE'nin bu sunucuda düzeltilip düzeltilmediği
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL ailesi: bu CVE'yi düzelten bir güncelleme olup olmadığı ve kurulu sürüm
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Paket adını (php8.3-fpm vb.) kendi ortamınıza göre uyarlayın. Görünen sürümü yukarıdaki tablodaki veya takipçideki “düzeltilmiş sürüm” ile karşılaştırın; aynıysa ya da daha yüksekse düzeltme yüklüdür. Ardından Tuzak 1'de anlatılan yeniden başlatma ve web tarafı kontrolünü tamamlayın.

PHP'yi dağıtımın kendi paketleri yerine üçüncü taraf bir depodan kuruyorsanız, o deponun güncellemelerini takip etmeniz gerekir. PHP duyurusu, gönüllülerce işletilen rpms.remirepo.net deposunda açıklama gününde güncelleme bulunmayacağını belirtiyor ve dağıtım paketlerine ya da kendi derlemelerinize geçmeyi öneriyor.

Tuzak 4: Paylaşımlı barındırma ve yönetilen ortamlarda PHP'yi kendiniz yükseltemezsiniz

Paylaşımlı barındırmada ve yönetilen PHP ortamlarında PHP çalışma zamanını sağlayıcı değiştirir. Burada da numara tek başına yetmez: sağlayıcı PHP'yi kendisi derliyorsa veya düzeltmeleri backport ediyorsa sürüm numarası eski kalabilir.

Kendiniz yapabileceğiniz üç şey var.

1. Web tarafındaki sürümü kontrol edin. Tuzak 1'deki geçici dosyayla PHP_VERSION ve PHP_SAPI değerlerini yazdırın, ardından hemen silin. Kontrol panelinde bir PHP sürüm seçici varsa hangi sürümü seçtiğinizi de not edin.
2. Sağlayıcının duyurusunu okuyun; yoksa sorun. Şunu sorun: “Paketimdeki hangi PHP sürümleri için CVE-2026-109618 ve CVE-2026-109619 düzeltmeleri ne zaman uygulanacak (veya uygulandı mı)?” Sürüm numarası yerine CVE numarasıyla sormak, backport'ları da kapsayan bir yanıt almanızı sağlar.
3. Desteklenmeyen bir sürüm seçtiyseniz yükseltin. PHP projesi 8.1 ve öncesi için düzeltme yayımlamıyor, 8.2'nin desteği de 2026-12-31'de bitiyor. Sağlayıcı düzeltmeleri backport etmediyse, sürüm değiştirmek güvenilir yoldur.

Barındırma sağlayıcılarına göre durum (2026-10-22 itibarıyla)

Paylaşımlı barındırmada PHP çalışma zamanını normalde sağlayıcı günceller ve birçok sağlayıcının duyurusunda “kullanıcılardan işlem gerekmediği” belirtilir. Kullanıcıların yapacağı iki şey var: sağlayıcılarının resmî duyurusunu kontrol etmek ve kontrol panelinde eski bir PHP sürümü seçtilerse, duyurunun önerdiği sürüme (düzeltilmiş sürümü olan bir sürüme) geçip geçmeyeceklerine karar vermek.

Aşağıdaki tablo yalnızca her sağlayıcının resmî sayfalarında (duyurular ve bakım bilgileri) yazanları, duyuru ifadelerini başka sözcüklerle aktararak özetler. Duyurular gelişmelere göre güncellenir; gerçek durumu mutlaka belirtilen resmî sayfadan doğrulayın.

Resmî duyuruyu bulamadığım veya açamadığım yerlerde tabloda “teyit edilemedi” ya da “bulunamadı” yazıyor. Orada bilgi bulunmaması, sağlayıcının yanıt vermediği anlamına gelmez. Doğrudan sağlayıcınızın duyurularından ve destek kanalından teyit edin.

Hemen güncelleyemediğiniz sürede alınabilecek önlemler

PHP duyurusu, güncelleme yapılana kadar saldırı yüzeyini azaltan ayarları listeliyor. Ancak duyurunun kendisi bunların “sizi güvenli kılmadığını” açıkça belirtiyor. Başlıcaları şunlar:

• CVE-2026-109619 için: php.ini, FPM havuzu veya sunucu yapılandırmasında session.upload_progress.enabled=0 ayarlayın ve tüm worker'ları yeniden başlatın (ini_set() ve FPM'in .user.ini dosyası bunun için işe yaramaz). PHP 8.5'te ayrıca fatal_error_backtraces=0 ayarlayın.
• CVE-2026-109618 için: memory_limit=-1 değerini uygulamanın geçersiz kılamayacağı bir biçimde ayarlayın ve post_max_size değerini düşürün (yükleme yoksa 8M, varsa 32M). RLIMIT_AS / RLIMIT_DATA değerlerini bunun yerine kullanmayın.

Birleşik Krallık NCSC'si, hemen güncellenemeyen veya önlem alınamayan sistemlerin çevrimdışı alınmasının düşünülmesini ve güncelleme ya da önlem uygulamadan önce ele geçirilme belirtilerinin kontrol edilmesini öneriyor.

Kaynaklar (2026-10-22'de kontrol edildi)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 sürüm duyuruları
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: resmî php imajı
• FrankenPHP 1.13.2 sürüm notları
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (düzeltilmiş paket sürümleri için Red Hat'in VEX verileri)
• NCSC: Critical security issue affecting PHP