PHP2Shell (CVE-2026-109618, CVE-2026-109619): Sunucunuzda Nasıl Tespit Edilir, Nasıl Kapatılır?

PHP2Shell, PHP çekirdeğindeki iki kritik açığın ortak adıdır: CVE-2026-109618 ve CVE-2026-109619 kimlik doğrulaması olmadan uzaktan kod çalıştırmaya izin verir ve PHP 8.5.12, 8.4.27, 8.3.36 ile 8.2.35’te kapatıldı. Tespit üç sorudur: hangi sürüm çalışıyor, hangi SAPI ile, ve izler loga düşüyor mu. Aşağıdaki iki betik üçünü de cevaplıyor.

Açıklar 20 Ekim 2026’da ambargo bitmeden sızdı ve yama planlanandan bir gün önce, 21 Ekim 14:00 UTC’de çıktı (PHP Foundation). Betikleri yamasız (8.4.26), yamalı (8.4.27) ve destek dışı (8.1) üç resmi Docker imajında sınadım; aşağıdaki çıktılar o testlerden. Sınarken iki şey öğrendim. Birincisi, geçici önlem ayarları CLI’de ve web sunucusunda farklı görünebiliyor; yanlış yerden bakan önlemi göremez. İkincisi, resmi PHP imajının varsayılan ayarında sömürünün en belirgin izi loga hiç düşmüyor.

PHP2Shell nedir ve neden bu kadar acil?

İki ayrı bellek hatasıdır ve ikisi de uygulama kodunuz çalışmadan önce tetiklenebilir. Resmi danışma notlarına göre:

	CVE-2026-109618	CVE-2026-109619
Kısa ad	OOM bozulması	Bayat global durum
Mekanizma	Bellek sınırı yarım başlatılmış bir veri yapısının ortasında aşılınca PHP, istek kapanışında geçersiz belleği okuyor	Ölümcül bir hata durumu sıfırlamayı atlatınca, aynı worker’daki sonraki istek serbest bırakılmış belleği kullanıyor
Bilinen tetik	Multipart gövde ayrıştırma: içerik uzunluğu belirsiz istekler, parça başına sınırsız başlık, iç içe alan adları	INI uyarıları ve oturum yükleme ilerlemesi (session.upload_progress, varsayılan açık)
Gösterilen sömürü	mod_php’de varsayılan ayarlarla kimliksiz RCE	mod_php’de RCE; oturum yolu FPM’de de doğrulandı
CVSS v4.0	9.2	9.2

Etkilenen SAPI’ler web isteği işleyen her şeydir: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Risk en yüksek mod_php’de, çünkü saldırı tek bir kimliksiz istekle ve uygulama kodu hiç çalışmadan tetiklenebiliyor. PHP 8.1 ve öncesi resmi güncelleme almıyor; güvenlik ekibi 7.4, 8.0 ve 8.1 için yalnız kaynaktan derleyenlere yönelik asgari yamalar yayımladı (php.net).

Sunucumda hangi PHP sürümü çalışıyor, savunmasız mı?

İlk betik yalnız okur. Sürümü düzeltme eşiğiyle karşılaştırır, dağıtım paketini gösterir, Apache’de mod_php yüklü mü ya da FPM çalışıyor mu diye bakar ve geçici önlem ayarlarını listeler:

#!/usr/bin/env bash
# php2shell-kontrol.sh: CVE-2026-109618 / CVE-2026-109619 için PHP sürümü,
# SAPI ve geçici önlem ayarlarını denetler. Yalnız okur, hiçbir şeyi değiştirmez.
# Kullanım: ./php2shell-kontrol.sh [php ikilisi]   (varsayılan: PATH'teki php)
set -u
PHP="${1:-php}"

if ! command -v "$PHP" >/dev/null 2>&1; then
  echo "php bulunamadı: $PHP"; exit 2
fi

ver=$("$PHP" -r 'echo PHP_VERSION;')
major_minor=$("$PHP" -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
patch=$("$PHP" -r 'echo PHP_RELEASE_VERSION;')

# Düzeltmeyi içeren ilk sürümler (php.net, 21 Ekim 2026)
case "$major_minor" in
  8.5) fixed=12 ;;
  8.4) fixed=27 ;;
  8.3) fixed=36 ;;
  8.2) fixed=35 ;;
  *)   fixed="" ;;
esac

echo "PHP sürümü      : $ver"
if [ -z "$fixed" ]; then
  verdict="SAVUNMASIZ (destek dışı dal; dağıtım backport'u yoksa yükseltin)"
elif [ "$patch" -ge "$fixed" ]; then
  verdict="YAMALI ($major_minor.$fixed ve üstü)"
else
  verdict="SAVUNMASIZ ($major_minor.$fixed gerekli)"
fi
echo "Sürüm kararı    : $verdict"

# Dağıtım paketleri düzeltmeyi eski sürüm numarasıyla da getirebilir.
if command -v dpkg-query >/dev/null 2>&1; then
  pkg=$(dpkg-query -S "$(command -v "$PHP")" 2>/dev/null | cut -d: -f1 | head -1)
  [ -n "$pkg" ] && echo "Paket           : $pkg $(dpkg-query -W -f='${Version}' "$pkg") (changelog'da CVE-2026-109618 arayın)"
elif command -v rpm >/dev/null 2>&1; then
  pkg=$(rpm -qf "$(command -v "$PHP")" 2>/dev/null)
  [ -n "$pkg" ] && echo "Paket           : $pkg (rpm -q --changelog ile CVE arayın)"
fi

# SAPI: mod_php en riskli olandır.
sapi="bilinmiyor"
for ctl in apache2ctl apachectl httpd; do
  if command -v "$ctl" >/dev/null 2>&1 && "$ctl" -M 2>/dev/null | grep -qi 'php'; then
    sapi="Apache mod_php (en yüksek risk)"; break
  fi
done
if [ "$sapi" = "bilinmiyor" ] && pgrep -f 'php-fpm' >/dev/null 2>&1; then
  sapi="PHP-FPM"
fi
echo "Web SAPI        : $sapi"

# Geçici önlemler: tam çözüm değildir, yalnız bilinen yolları daraltır.
ini() { "$PHP" -r "echo var_export(ini_get('$1'), true);"; }
echo "session.upload_progress.enabled = $(ini session.upload_progress.enabled)  (önlem: 0)"
echo "memory_limit                    = $(ini memory_limit)  (önlem: -1, admin düzeyinde)"
echo "post_max_size                   = $(ini post_max_size)  (önlem: 8M, yükleme varsa 32M)"
echo "log_errors                      = $(ini log_errors)  (iz için: 1)"
echo "display_errors                  = $(ini display_errors)  (üretimde: 0)"
if [ "$major_minor" = "8.5" ]; then
  echo "fatal_error_backtraces          = $(ini fatal_error_backtraces)  (önlem: 0)"
fi
echo "Not: CLI ini değerleri web havuzunun değerlerinden farklı olabilir; FPM havuzunu ve Apache yapılandırmasını ayrıca okuyun."

Üç resmi imajda çıktı şöyle:

$ docker run --rm -i php:8.4.26-apache bash -s < php2shell-kontrol.sh
PHP sürümü      : 8.4.26
Sürüm kararı    : SAVUNMASIZ (8.4.27 gerekli)
Web SAPI        : Apache mod_php (en yüksek risk)
session.upload_progress.enabled = '1'  (önlem: 0)
memory_limit                    = '128M'  (önlem: -1, admin düzeyinde)
post_max_size                   = '8M'  (önlem: 8M, yükleme varsa 32M)
log_errors                      = '0'  (iz için: 1)
display_errors                  = '1'  (üretimde: 0)

$ docker run --rm -i php:8.4.27-apache bash -s < php2shell-kontrol.sh
PHP sürümü      : 8.4.27
Sürüm kararı    : YAMALI (8.4.27 ve üstü)
Web SAPI        : Apache mod_php (en yüksek risk)
...

$ docker run --rm -i php:8.1-apache bash -s < php2shell-kontrol.sh
PHP sürümü      : 8.1.34
Sürüm kararı    : SAVUNMASIZ (destek dışı dal; dağıtım backport'u yoksa yükseltin)
Web SAPI        : Apache mod_php (en yüksek risk)
...

Yamalı imajda da session.upload_progress.enabled 1 kalıyor; bu beklenen bir durum, çünkü yama ayarı değiştirmez, açığı kapatır.

Dağıtım paketlerinde sürüm numarası yanıltabilir. Debian, Ubuntu ve RHEL düzeltmeyi çoğu zaman eski sürüm numarasına backport eder; 8.2.20 görünen bir paket yamalı olabilir. Betik bu yüzden paket adını da basıyor. Karar için paket değişiklik kaydına bakın:

apt changelog php8.2 2>/dev/null | grep -m1 CVE-2026-109618   # Debian / Ubuntu
rpm -q --changelog php | grep -m1 CVE-2026-109618              # RHEL / Alma / Rocky

Konteynerlerde ve panellerde PHP’yi nasıl bulurum?

Sunucunun kendi php ikilisi hikâyenin yalnız bir kısmı. Coolify, Portainer ya da elle kurulmuş her yığında PHP genellikle konteynerin içindedir. Çalışan bütün konteynerleri tek döngüyle sorabilirsiniz:

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  printf '%-12s %s\n' "$c" "$v"
done

eski-test    8.1.34
api-test     8.4.27
wp-test      8.4.26

Listeye panellerin kendisini de katın: Coolify gibi PHP ile yazılmış yönetim panelleri de bir PHP yığınıdır. Taşınmış ya da kullanılmayan uygulamaları atlamayın. Alan adının DNS kaydı başka bir sunucuyu gösterse bile ters vekil (reverse proxy) doğru Host başlığıyla gelen isteği eski konteynere yönlendirmeye devam eder ve konteyner internetten erişilebilir kalır. wordpress:latest gibi bir etiket de kendiliğinden güncellenmez; imaj yeniden çekilip konteyner yeniden oluşturulana kadar ilk kurulumdaki PHP sürümü çalışır.

cPanel (EA-PHP), Plesk ve CloudLinux (alt-php) aynı sunucuda birden çok PHP sürümü barındırır. Panelin PHP seçici ekranında listelenen her sürüm ayrı ayrı yamalanmalıdır; site başına seçilen sürüm hangisiyse asıl risk odur.

Sürüm dışarıdan görünüyor mu?

Çoğu zaman evet ve bu saldırganın işini kolaylaştırır. PHP varsayılan olarak her yanıta sürümünü ekler:

$ curl -sI http://localhost:18080/index.php | grep -iE '^server|x-powered'
Server: Apache/2.4.69 (Debian)
X-Powered-By: PHP/8.4.26

Testte resmi php.ini-production dosyasını etkinleştirdikten sonra da başlık yerinde kaldı, çünkü o dosyada expose_php hâlâ On. Başlığı kapatmak için expose_php = Off yazmanız gerekir. Bu bir yama değildir, yalnız envanter çıkaran tarayıcıların işini zorlaştırır. Aynı komutu kendi alan adınıza karşı çalıştırmak, dışarıdan nasıl göründüğünüzü gösteren en hızlı ölçümdür.

PHP2Shell nasıl kapatılır?

Tek tam çözüm yamalı sürüme geçip her worker’ı yeniden başlatmaktır. Sürüm eşiği: 8.5.12, 8.4.27, 8.3.36 veya 8.2.35.

Ortam	Komut
Debian / Ubuntu (dağıtım paketi)	sudo apt update && sudo apt install --only-upgrade 'php*', ardından sudo systemctl restart apache2 'php*-fpm' (kullandığınız servisler)
RHEL / Alma / Rocky	sudo dnf upgrade 'php*', ardından sudo systemctl restart httpd php-fpm
Docker (resmi imaj)	Etiketi yamalı sürüme sabitleyin (örneğin php:8.4.27-apache) ya da wordpress:php8.3-apache gibi etiketi yeniden çekin, sonra docker compose pull && docker compose up -d --force-recreate
Coolify	İmajı yeniden çekerek yeniden dağıtın; yalnız yeniden başlatmak imajı yenilemez
Paylaşımlı hosting	Sağlayıcıdan yazılı teyit isteyin, paneldeki PHP sürümünü kontrol edin

php.net duyurusu, gönüllülerin yürüttüğü rpms.remirepo.net deposunda yama günü güncelleme olmayacağını ayrıca yazdı. Remi kullanıyorsanız bunu doğrulamadan “güncelledim” demeyin.

Yamadan sonra sürümü web üzerinden okuyun. CLI’nin ikilisi ile web sunucusunun yüklediği modül farklı olabilir; bir sonraki bölümdeki test bunun neden önemli olduğunu gösteriyor.

Yama hemen yapılamıyorsa hangi geçici önlemler işe yarar?

Kısmen işe yarar ve hiçbiri tam çözüm değildir. Resmi danışma notları her açık için ayrı önlem veriyor:

Açık	Önlem	Kapattığı
CVE-2026-109619	session.upload_progress.enabled=0	Oturum yolunu; diğer yaşam döngüsü yollarını kapatmaz
CVE-2026-109619 (yalnız 8.5)	fatal_error_backtraces=0	8.5’teki gösterilmiş RCE yolunu
CVE-2026-109618	memory_limit=-1 + düşük post_max_size + web sunucusunda istek boyutu, alan sayısı ve multipart parça sınırları	OOM yollarının çoğunu; mmap() hatası yolu açık kalır
İkisi	Multipart kullanmıyorsanız ön uçta multipart isteği engellemek	Bilinen tetiklerin hepsini

Bu ayarlar istek ayrıştırılmadan önce uygulanmalıdır: php.ini, FPM havuzu (php_admin_value) ya da Apache yapılandırması. Uygulama içindeki ini_set() ve FPM .user.ini işe yaramaz, çünkü saldırı o satırlara gelinmeden tetiklenir. Apache mod_php’de test ettiğim yapılandırma:

# /etc/apache2/conf-enabled/php2shell-gecici.conf
# PHP2Shell geçici önlemler (yama gelene kadar; tam çözüm değil)
php_admin_flag  session.upload_progress.enabled off
php_admin_value memory_limit -1

Önlemin uygulandığını CLI ile doğrulayamazsınız. Aynı konteynerde web üzerinden okuyan küçük bir sayfa ile CLI farklı sonuç verdi:

$ curl -s http://localhost:18080/ini.php     # web SAPI (mod_php)
session.upload_progress.enabled = '0'
memory_limit = '-1'

$ docker exec p2s php -r 'echo ini_get("session.upload_progress.enabled");'   # CLI
1

Apache yapılandırması yalnız Apache’nin yüklediği modülü etkiler, CLI kendi php.ini’sini okur. Önlemi CLI ile kontrol eden biri “uygulanmamış” der ve yanlış alarm verir; tersi de mümkündür: CLI’nin php.ini’sine yazılan önlem web tarafına hiç ulaşmaz. Kontrol sayfasını işiniz bitince silin. memory_limit=-1 kullanıyorsanız yanına yalnız o worker’ı öldüren bir konteyner bellek sınırı koyun; RLIMIT_AS ve RLIMIT_DATA kullanmayın, danışma notu bunların savunmasız yolu tetikleyebildiğini yazıyor.

Sunucumun sömürülüp sömürülmediğini nasıl anlarım?

Üç iz aranır: PHP worker’ından doğan kabuk ya da indirme aracı, hata loglarında bellek taşması ve çökme yoğunluğu, ve son günlerde ortaya çıkan .php dosyaları. CISA da aynı işaretleri öneriyor: PHP worker süreçlerinin kabuk başlatması veya araç indirmesi (CISA). İkinci betik üçüne birden bakar:

#!/usr/bin/env bash
# php2shell-iz.sh: PHP2Shell sonrası iz avı. Yalnız okur.
# 1) PHP worker'ından doğmuş kabuk ve indirme araçları
# 2) Hata loglarında bellek taşması ve worker çökmesi yoğunluğu
# 3) Belirli bir tarihten sonra değişmiş .php dosyaları
# Kullanım: ./php2shell-iz.sh [web kökü] [tarih]
set -u
WEBROOT="${1:-/var/www}"
SINCE="${2:-2026-10-17}"   # ilk sömürü denemesi 17 Ekim'de görüldü

echo "== 1) PHP süreçlerinin çocukları"
ps -eo pid,ppid,user,comm,args --no-headers | awk '
  { pid[$1]=$4; line[$1]=$0; parent[$1]=$2 }
  END {
    for (p in line) {
      c = pid[p]; par = pid[parent[p]]
      if (par ~ /^(apache2|httpd|php-fpm|php-fpm[0-9.]*|lsphp|frankenphp)$/ &&
          c ~ /^(sh|bash|dash|zsh|curl|wget|python[0-9.]*|perl|nc|ncat|socat|busybox)$/)
        print "  SUPHELI: " par " -> " line[p]
    }
  }' | sort -u
echo "  (satır yoksa temiz)"

echo "== 2) Hata loglarında OOM ve çökme"
if command -v php >/dev/null 2>&1 && [ "$(php -r 'echo (int) ini_get("log_errors");')" = "0" ]; then
  echo "  UYARI: log_errors=0, PHP fatal hataları loga yazılmıyor; aşağıdaki sayım kör"
fi
logs=$(ls /var/log/apache2/error*.log /var/log/httpd/error*log /var/log/php*-fpm.log /var/log/php-fpm/*.log 2>/dev/null)
if [ -z "$logs" ]; then
  echo "  log dosyası bulunamadı (konteynerde stderr'e gidiyor olabilir: docker logs <ad>)"
else
  for f in $logs; do
    oom=$(grep -c 'Allowed memory size of' "$f")
    seg=$(grep -Ec 'Segmentation fault|signal 11|SIGSEGV|zend_mm_heap corrupted' "$f")
    echo "  $f: OOM=$oom cokme=$seg"
  done
fi

echo "== 3) $SINCE sonrası değişen .php dosyaları ($WEBROOT)"
find "$WEBROOT" -type f -name '*.php' -newermt "$SINCE" -printf '  %TY-%Tm-%Td %TH:%TM  %u  %p\n' 2>/dev/null | sort | head -50
echo "  (güncelleme yaptıysanız eklenti dosyaları da burada görünür; sahibine ve yoluna bakın)"

Betiği sınamak için yamasız imajda üç iz ürettim: bellek sınırını aşan bir sayfaya üç istek, system() ile bir alt süreç açan bir sayfa ve honeypot’ta gördüğüm webshell’in adını taşıyan bir dosya. İlk çıktı:

== 1) PHP süreçlerinin çocukları
  SUPHELI: apache2 ->      59      58 www-data sh              sh -c -- sleep 25
== 2) Hata loglarında OOM ve çökme
  UYARI: log_errors=0, PHP fatal hataları loga yazılmıyor; aşağıdaki sayım kör
  /var/log/apache2/error.log: OOM=0 cokme=0
== 3) 2026-10-17 sonrası değişen .php dosyaları (/var/www)
  2026-10-22 09:13  root  /var/www/html/index.php
  2026-10-22 09:13  root  /var/www/html/k.php
  2026-10-22 09:13  root  /var/www/html/oom.php
  2026-10-22 09:13  root  /var/www/html/zzc228ee1463.php

Üç bellek taşması isteği yapıldığı halde log sıfır gösterdi. Sebep resmi imajın varsayılanı: php.ini yokken log_errors=0 ve display_errors=1. Hata loga değil, isteği yapanın ekranına yazılıyor; üç istek de 200 döndü ve gövdede Allowed memory size of 134217728 bytes exhausted yazıyordu. Yani saldırgan bellek taşmasını tetiklediğini görüyor, siz görmüyorsunuz. php.ini-production etkinleştirilip aynı üç istek tekrarlanınca:

== 2) Hata loglarında OOM ve çökme
  /var/log/apache2/error.log: OOM=3 cokme=0

[php:error] [pid 120:tid 120] [client 172.17.0.1:50880] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 314572832 bytes) in /var/www/html/oom.php on line 1

Bu kez istekler 500 döndü, hata istemciye gösterilmedi ve log her birini kaydetti. Normal bir sitede kısa sürede çok sayıda bellek taşması, ardından worker çökmesi (Segmentation fault, exited on signal 11) CVE-2026-109618 denemesinin en olası görüntüsüdür. Yeni .php dosyaları listesinde kendi güncellemeleriniz de çıkar; sahibi www-data olan ve yükleme dizinlerinde duran dosyalar önce incelenir. Şüpheli bir süreç ya da dosya bulduysanız sunucuyu kapatmadan önce disk ve bellek görüntüsü alın, sonra temiz kurulumdan geri dönmeyi planlayın; yama, içeri girmiş birini çıkarmaz.

Honeypot’ta PHP2Shell görüldü mü?

Bizim sensörde görülmedi. Tellal honeypot ağı 15-22 Ekim’de PHP_SESSION_UPLOAD_PROGRESS alanını içeren tek bir istek bile kaydetmedi; sızıntı penceresinde gelen PHP saldırıları eski tekniklerdi: bir WordPress eklentisi üzerinden GIF89a başlıklı webshell yükleme denemesi ve 2012’den kalma php-cgi argüman enjeksiyonu (Tellal bülteni). Bu sıfır, sizin sunucunuzun güvende olduğunu göstermez: Cloudflare yama öncesinde erken saldırılar gördüğünü açıkladı ve HTTPS gövdeleri sensörde görünmez. Yamanın zamanlaması bir honeypot sessizliğine bağlanmamalıdır.

Kurumsal tarafı, yani hangi sistemlerin önce ele alınacağı, sağlayıcıya ne sorulacağı ve 48 saatlik eylem listesi SiberKale’deki yazıda.

Bugün yapılacakların kısa listesi nedir?

1. php2shell-kontrol.sh ile her sunucuyu ve konteyner döngüsüyle her konteyneri tarayın; panel ve hosting hesaplarını da listeye ekleyin.
2. Yamalı sürüme geçin ve her worker’ı yeniden başlatın; konteynerleri yeniden oluşturun.
3. Sürümü web üzerinden doğrulayın (X-Powered-By ya da kontrol sayfası), CLI ile değil.
4. Yama gecikecekse geçici önlemleri php.ini, FPM havuzu ya da Apache yapılandırmasına yazın ve yine web üzerinden doğrulayın.
5. log_errors=1 ve display_errors=0 yapın; yoksa iz avı kördür.
6. php2shell-iz.sh ile 17 Ekim’den bu yana süreç, log ve dosya izlerini tarayın.
7. expose_php = Off ile sürüm ilanını kapatın.

Altyapınızın tamamında PHP envanteri ve yama doğrulaması için siber güvenlik ve sistem yönetimi sayfalarından bana ulaşabilirsiniz.