PHP2Shell: Ubuntu'da PHP yamasını doğrulayın

PHP2Shell yaması Ubuntu'da kurulu mu, nasıl anlarsınız?

PHP2Shell yamasının Ubuntu sunucunuzda kurulu olup olmadığını php -v ile anlayamazsınız. Ubuntu, güvenlik düzeltmelerini PHP'nin upstream sürüm numarasını değiştirmeden kendi paketine ekler. Doğru kontrol, paketin tam sürümünü dpkg-query ile okumak ve Canonical'ın yayımladığı düzeltilmiş sürümle dpkg --compare-versions ile karşılaştırmaktır. Ardından PHP-FPM'i ya da Apache'yi yeniden başlatırsınız. Güncelleme diskteki dosyaları değiştirir, bellekte çalışan eski kodu değiştirmez.

Bu rehber WordPress, Laravel ya da bir yönetim paneli çalıştıran Ubuntu VPS sahipleri için yazıldı. Komutların çoğu ağ bağlantısı olmadan, yerel paket veritabanı üzerinden çalışır. Ağ isteyen adımları ayrıca belirttik.

PHP2Shell nedir, neden bu kadar ciddi?

PHP2Shell, iki ayrı açığa verilen ortak addır: CVE-2026-109618 ve CVE-2026-109619. CVE (Common Vulnerabilities and Exposures), herkese açık güvenlik açıklarına verilen kimlik numarasıdır. İki açık da RCE (remote code execution, uzaktan kod çalıştırma) türündedir. Saldırgan sunucunuzda kendi kodunu çalıştırabilir ve bunun için oturum açması gerekmez. PHP projesi iki açığı da CVSS v4.0 ölçeğinde 9.2 puanla Kritik olarak derecelendirdi. CVSS (Common Vulnerability Scoring System), açıkların ciddiyetini puanlayan ortak sistemdir.

php.net duyurusu iki açığı şöyle anlatıyor. CVE-2026-109618 bellek yetersizliği (OOM, out of memory) sırasında ortaya çıkar. PHP, istek verisi henüz yarım hazırlanmışken kesilebilir. İstek temizliği de bu geçersiz veriyi geçerli sanar. CVE-2026-109619'da ise bir isteğe ait iç durum, arkasındaki bellek serbest bırakıldıktan sonra da yaşamaya devam eder.

Düzeltmeler 21 Ekim 2026'da yayımlandı: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. GitHub'daki güvenlik bildirimleri bu dört sürümün altındaki her sürümü etkilenmiş sayıyor. php.net'e göre web isteği karşılayan tüm PHP kurulumları risk altında. Buna PHP-FPM, Apache ile mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil. php.net en yüksek riskin mod_php'de olduğunu yazıyor. Orada kimliği doğrulanmamış tek bir istek, uygulamanızın ilk satırı çalışmadan saldırıyı tetikleyebiliyor ve bunun gösterilmiş bir istismarı var.

Tarih de önemli. Amazon Threat Intelligence, kendi tuzak (honeypot) ağı MadPot'ta 17 Ekim 2026 tarihli bir PHP2Shell istismar girişimi gördüğünü açıkladı. Bu, açığın duyurulmasından dört gün önceye denk geliyor. Bu yüzden rehberin sonunda yalnızca yamaya değil, sunucunun temiz olup olmadığına da bakacağız.

Neden php -v eski sürümü gösteriyor?

Önce komutu kendiniz çalıştırın ve ilk satırı okuyun:

php -v

Buradaki numarayı php.net'teki 8.3.36 ile karşılaştırmak yanlış sonuç verir. Ubuntu bir LTS (long term support, uzun süreli destek) sürümü çıkardığında PHP'nin bir sürümünü o noktada sabitler. Sonraki güvenlik düzeltmeleri bu sabit sürümün üstüne yama olarak eklenir. Değişen kısım, paket sürümünün sonundaki Ubuntu ekidir.

Örnek olarak Ubuntu 24.04 için düzeltilmiş paket sürümüne bakın: 8.3.6-0ubuntu0.24.04.13. Baştaki 8.3.6, paketin dayandığı upstream PHP sürümüdür. Sondaki -0ubuntu0.24.04.13 ise Ubuntu'nun revizyonudur ve her güvenlik güncellemesiyle büyür. php -v size PHP kaynağının numarasını gösterir. Hangi Ubuntu yamalarının eklendiğini bu numaradan çıkaramazsınız. Kanıt, paketin tam sürümündedir.

Ubuntu 22.04'teki PHP 8.1 de aynı mantıkla çalışır. php.net'e göre PHP 8.1 ve öncesi artık PHP projesinden güncelleme almıyor. PHP güvenlik ekibi yine de 7.4, 8.0 ve 8.1 için kaynak düzeyinde küçük geri taşımalar (backport) yayımladı. Canonical da 22.04'teki php8.1 paketi için düzeltilmiş bir sürüm çıkardı. Yani upstream'de karşılığı olmayan bir sürümde bile yamalı olabilirsiniz.

Hangi Ubuntu sürümündesiniz?

Düzeltilmiş sürüm, Ubuntu sürümüne göre değişir. Önce kod adını öğrenin:

. /etc/os-release
echo "$VERSION_ID $VERSION_CODENAME"

Çıktı sürüm numarasını ve noble ya da jammy gibi bir kod adını verir. Bu kod adını aşağıdaki listede bulun.

Ubuntu'da PHP2Shell için düzeltilmiş paket sürümleri

Canonical'ın iki CVE sayfası ile USN-8948-1 ve USN-8948-2 bildirimleri (USN, Ubuntu Security Notice) her sürüm için düzeltilmiş paketi listeliyor. Ubuntu bu açıklara "Critical" önceliği verdi. İki CVE için düzeltilmiş sürüm aynı, bu yüzden her Ubuntu sürümünde tek bir karşılaştırma yeterli. 22 Ekim 2026'da bu sayfalardan okuduğumuz değerler:

• Ubuntu 26.10 (stonking): php8.5 serisi, en az 8.5.9-0ubuntu2.1
• Ubuntu 26.04 LTS (resolute): php8.5 serisi, en az 8.5.4-0ubuntu1.5
• Ubuntu 24.04 LTS (noble): php8.3 serisi, en az 8.3.6-0ubuntu0.24.04.13
• Ubuntu 22.04 LTS (jammy): php8.1 serisi, en az 8.1.2-1ubuntu2.28
• Ubuntu 20.04 LTS (focal): php7.4 serisi, en az 7.4.3-4ubuntu2.29+esm5, yalnızca Ubuntu Pro ile

Bu değerler yeni bir güncelleme geldiğinde geçersiz olmaz. Daha yeni bir güvenlik düzeltmesi paket sürümünü büyütür. Aşağıdaki karşılaştırma "büyük veya eşit" sorduğu için o zaman da doğru sonucu verir.

USN-8948-1 bildirimi düzeltilmiş ikili paketler arasında php8.x-cli, php8.x-fpm, php8.x-cgi ve libapache2-mod-php8.x paketlerini sayıyor. Komut satırı, FPM ve Apache modülü ayrı paketlerdir. Hepsinin güncel olması gerekir.

Kurulu PHP paketlerini listeleyin

Bu komut yerel paket veritabanını okur. Ağ gerekmez:

dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null | grep '^ii'

dpkg-query -W her eşleşen paket için bir satır yazar. -f çıktı biçimini belirler. ${db:Status-Abbrev} üç karakterlik paket durumudur ve ii paketin kurulu olduğunu gösterir. grep '^ii' kaldırılmış ama ayar dosyaları kalmış paketleri dışarıda bırakır.

Listede php8.3-fpm gibi seri numarası taşıyan adlar göreceksiniz. Karşılaştırmayı bunlar üzerinde yapın. php-fpm gibi numarasız adlar sizi sürümlü pakete yönlendiren meta paketlerdir. Ubuntu sürümünüzün listesinde olmayan bir seri görürseniz, örneğin 24.04 üzerinde php8.1, paketin nereden geldiğini şu komutla görün:

apt-cache policy php8.1-fpm

Bu komut da yerel depo listelerini okur. Çıktıdaki kaynak satırı Ubuntu arşivini değil de bir PPA'yı (Personal Package Archive, kişisel paket deposu) gösteriyorsa, aşağıdaki Ondrej PPA bölümüne geçin.

dpkg --compare-versions ile karşılaştırın

Debian sürüm numaraları düz metin gibi karşılaştırılamaz. 0ubuntu0.24.04.13 ile 0ubuntu0.24.04.9 arasında hangisinin büyük olduğunu bir metin sıralaması yanlış söyler. dpkg --compare-versions bu kuralları bilir. Koşul doğruysa 0, yanlışsa 1 çıkış koduyla döner. Karşılaştırma için lt (küçük) ve ge (büyük veya eşit) gibi operatörleri kullanın. dpkg man sayfası eski < ve > operatörlerini kafa karıştırıcı anlamları yüzünden kullanılmaz sayıyor.

Aşağıdaki betik kod adına göre düzeltilmiş sürümü seçer ve kurulu her sürümlü PHP paketini onunla karşılaştırır:

cat > php2shell-kontrol.sh <<'EOF'
#!/bin/bash
. /etc/os-release
case "$VERSION_CODENAME" in
  stonking) SERI=8.5; DUZELTME=8.5.9-0ubuntu2.1 ;;
  resolute) SERI=8.5; DUZELTME=8.5.4-0ubuntu1.5 ;;
  noble)    SERI=8.3; DUZELTME=8.3.6-0ubuntu0.24.04.13 ;;
  jammy)    SERI=8.1; DUZELTME=8.1.2-1ubuntu2.28 ;;
  focal)    SERI=7.4; DUZELTME=7.4.3-4ubuntu2.29+esm5 ;;
  *) echo "Bu kod adi listede yok: $VERSION_CODENAME"; exit 2 ;;
esac
echo "Kod adi: $VERSION_CODENAME, seri: php$SERI, en az: $DUZELTME"
dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' \
  "php$SERI*" "libapache2-mod-php$SERI" 2>/dev/null |
while read -r durum paket surum; do
  [ "$durum" = "ii" ] || continue
  if dpkg --compare-versions "$surum" ge "$DUZELTME"; then
    echo "YAMALI  $paket $surum"
  else
    echo "ESKI    $paket $surum"
  fi
done
EOF
bash php2shell-kontrol.sh

Her satır YAMALI ya da ESKI ile başlar. ge eşitliği de kapsadığı için, kurulu sürüm düzeltilmiş sürümün tam kendisiyse satır yine YAMALI olur. 20.04 dışındaki sürümlerde Ubuntu arşivinden yeni kurulan PHP paketleri düzeltilmiş sürümle ya da daha yenisiyle gelir, bu yüzden yeni kurulmuş bir sunucuda ESKI görmezsiniz. ESKI satırı, PHP'si daha önce kurulmuş ve o zamandan beri güncellenmemiş sunucularda çıkar. Tek bir ESKI satırı bile yeterli bir uyarıdır, çünkü web isteklerine hangi paketin cevap verdiğini o satır tek başına söylemez. Betik yalnızca başlık satırını yazıp duruyorsa, bu seride Ubuntu arşivinden kurulmuş bir PHP paketi yoktur. O zaman önceki bölümdeki listeye dönün ve PHP'nin nereden geldiğini bulun.

Betiğin bir sınırı var. Yalnızca Ubuntu arşivindeki paketler için anlamlıdır. Upstream numarası taşıyan bir PPA paketi, örneğin 8.3.20 tabanlı bir paket, Ubuntu'nun 8.3.6-... sürümünden her zaman büyük görünür. Betik onu YAMALI diye yazar, ama bu bir şey kanıtlamaz.

Güncellemeyi kurun

Betik ESKI dediyse güncellemeyi kurun. Bu adım ağ ister:

sudo apt update
sudo apt upgrade
bash php2shell-kontrol.sh

USN-8948-1 bildirimi, standart bir sistem güncellemesinin gerekli değişikliklerin hepsini yapacağını söylüyor. apt upgrade bağımlılık hatası verip duruyorsa önce paket durumunu düzeltin. apt'de bozuk paketleri düzeltme rehberi en sık görülen hataları ve nedenlerini anlatıyor. Sunucunuz güvenlik güncellemelerini zaten otomatik kuruyorsa paket güncellenmiş olabilir. Yine de betikle doğrulayın. Otomatik güncellemenin nasıl kurulduğunu ve neyi kurmadığını Ubuntu'da unattended-upgrades ile otomatik güvenlik güncellemeleri yazımızda bulabilirsiniz.

Bir kontrolü daha siz çalıştırabilirsiniz. Bu kontrol ağa bağlanır: Ubuntu Pro istemcisinin pro fix komutu. --dry-run sistemi değiştirmeden ne yapacağını gösterir. Çıktı etkilenen paketi ve düzeltmeyi uygulayacak apt komutunu adıyla yazar:

sudo pro fix --dry-run CVE-2026-109619
sudo pro fix CVE-2026-109619

Ubuntu 20.04 ve PHP 7.4 kullanıyorsanız

Ubuntu 20.04 için düzeltme, USN-8948-2 bildirimine göre yalnızca Ubuntu Pro üzerinden geliyor. Pro'suz bir 20.04 sunucuda apt upgrade bu düzeltmeyi getirmez. Paket 7.4.3-4ubuntu2.29+esm5 sürümüne ulaşmaz. ESM (Expanded Security Maintenance, genişletilmiş güvenlik bakımı), standart destek süresi biten sürümler için Canonical'ın sağladığı güvenlik güncellemeleridir.

ubuntu.com/pro sayfası, Pro'nun kişisel kullanım için 5 fiziksel makineye kadar ücretsiz olduğunu yazıyor. Pro belgeleri ise kişisel ve küçük ölçekli ticari kullanım için 5 makineden söz ediyor. İki sayfa farklı ifade kullanıyor ve bir VPS sanal bir makine. Sunucunuzun bu kapsama girip girmediğini ubuntu.com/pro üzerindeki güncel şartlardan kendiniz kontrol edin. Pro'nun bir sunucuya ne kattığını Ubuntu Pro'nun sunucuda ne işe yaradığını anlatan yazımızda ayrıntılı ele aldık.

16.04 ve 14.04 için düzeltmeler ayrıca Legacy Support eklentisini istiyor. Bu kadar eski bir sunucuda uzun vadeli doğru adım, desteklenen bir Ubuntu sürümüne geçmektir.

Neden PHP-FPM ya da Apache'yi yeniden başlatmalısınız?

apt upgrade diskteki dosyaları yenisiyle değiştirir. Çalışan bir süreç ise başladığı anda belleğe yüklediği kodla çalışmaya devam eder. PHP-FPM (FastCGI Process Manager) uzun süre yaşayan işçi süreçleri çalıştırır. mod_php ise Apache süreçlerinin içinde yaşar. Bu süreçler yeniden başlamadıkça istekleri eski, açıklı kodla karşılarlar.

Ubuntu belgelerine göre 24.04 LTS ve sonrasında unattended-upgrades, güncellemeden sonra needrestart aracını çağırır ve etkilenen servisleri varsayılan olarak otomatik yeniden başlatır. Belgeler bunu otomatik güncellemeler için söylüyor. Elle çalıştırdığınız apt upgrade için aynı şeyi varsaymayın. Kontrol edin.

Önce PHP'yi çalıştıran servislerin adlarını bulun:

systemctl list-units --type=service --no-pager | grep -Ei 'php|apache|httpd|litespeed|frankenphp'

Sonra PHP paketlerinin ne zaman güncellendiğine bakın:

grep -E ' upgrade (php|libapache2-mod-php)' /var/log/dpkg.log | tail -n 5

Şimdi her servisin en son ne zaman başladığını görün. BIRIM_ADI yerine ilk komutun çıktısındaki adı yazın:

systemctl show -p ActiveEnterTimestamp BIRIM_ADI

Başlama zamanı güncelleme zamanından eskiyse, servis hâlâ eski kodu çalıştırıyor demektir. O servisi yeniden başlatın ve aynı kontrolü tekrarlayın:

sudo systemctl restart BIRIM_ADI
systemctl show -p ActiveEnterTimestamp BIRIM_ADI

Birden fazla PHP-FPM servisi görüyorsanız, örneğin iki farklı PHP serisi kuruluysa, her birini ayrı ayrı yeniden başlatın. Sitenizin hangisini kullandığını tahmin etmeyin.

CLI ve FPM neden farklı php.ini okur?

PHP, yapılandırmasını SAPI'ye (Server API, PHP'nin komut satırı ya da web sunucusuyla konuştuğu katman) göre arar. php.net kılavuzuna göre PHP önce o SAPI'ye özel php-SAPI.ini dosyasını, bulamazsa php.ini dosyasını arar. Ek olarak tarama dizinindeki dosyaları da okur. Bu yüzden terminalde gördüğünüz ayar, web isteklerine cevap veren FPM süreçlerinin ayarı olmayabilir. Hangi dosyaların yüklendiğini tahmin etmeyin, PHP'ye sorun.

Komut satırı için:

php --ini

FPM için önce ikili dosyanın adını bulun, sonra aynı soruyu ona sorun:

compgen -c | grep '^php-fpm' | sort -u
sudo php-fpm8.3 -i | grep -Ei 'loaded configuration|scan this dir|upload_progress.enabled'

İkinci komutta php-fpm8.3 yerine birinci komutun çıktısındaki adı kullanın. Çıktıda iki yol göreceksiniz: yüklenen yapılandırma dosyası ve ek .ini dosyalarının okunduğu tarama dizini. Bu yolları not edin, bir sonraki bölümde gerekecek.

Bir ayrıntı önemli. php-fpm8.3 -i yeni bir süreç başlatır ve yapılandırma dosyalarını o anda okur. Size dosyalarda ne yazdığını gösterir, çalışan işçilerin bellekteki değerini göstermez. Bir ayarı değiştirdikten sonra servisi yeniden başlatmadıysanız bu çıktı yeni değeri gösterir ama işçiler eski değerle çalışmaya devam eder.

mod_php'nin sorgulanabilecek ayrı bir ikili dosyası yoktur. Onun yüklediği dosyaları görmek için tahmin edilemez adlı geçici bir phpinfo() dosyası açıp "Loaded Configuration File" satırını okuyabilirsiniz. Okuduktan hemen sonra dosyayı silin, çünkü bu sayfa sunucunuz hakkında saldırgana da çok şey anlatır.

Geçici önlem: session.upload_progress.enabled=0

php.net, güncellemeyi hemen kuramayanlar için CVE-2026-109619'a karşı bir ara önlem yayımladı: session.upload_progress.enabled=0 ayarı ve ardından her işçinin yeniden başlatılması. Bu önlem geçicidir. php.net'e göre doğrulanmış oturum yollarını kapatır ama açığın diğer varyantlarını kapatmaz. Tam çözüm yalnızca güncellemedir.

Önce mevcut değeri görün. Bu, komut satırının değeridir:

php -i | grep session.upload_progress

Çıktıyı kendi sunucunuzda okuyun. PHP kılavuzu bu ayarın varsayılanını 1, yani açık olarak veriyor. Dağıtımın php.ini dosyası farklı bir değer koymuş olabilir, bu yüzden bir önceki bölümde FPM için gördüğünüz değeri de ayrıca okuyun.

Ayar INI_PERDIR türündedir, yani çalışma anında ini_set() ile değiştirilemez. php.net bu önlem için ini_set() ya da FPM .user.ini dosyasına güvenmemenizi açıkça söylüyor. Ayar, istek ayrıştırılmadan önce uygulanan bir yerde olmalı: php.ini, bir FPM havuz yapılandırması ya da sunucu yapılandırması. En temiz yol, FPM'in tarama dizinine ayrı bir dosya koymaktır. TARAMA_DIZINI yerine php-fpm8.3 -i çıktısındaki "Scan this dir" yolunu yazın:

echo 'session.upload_progress.enabled = 0' | sudo tee TARAMA_DIZINI/99-php2shell-gecici.ini
sudo php-fpm8.3 -i | grep upload_progress.enabled
sudo systemctl restart BIRIM_ADI

Ayrı bir dosya kullanmanın nedeni şu: güncellemeyi kurduktan sonra ne değiştirdiğinizi bilirsiniz ve tek dosyayı silerek geri alabilirsiniz. mod_php kullanıyorsanız aynı satırı Apache'nin PHP'sinin tarama dizinine koyun ve Apache'yi yeniden başlatın.

Güncellemeden sonra bu ayarı kapalı bırakmak da makul olabilir. GitHub bildirimi, özelliğe ihtiyacınız yoksa yamadan sonra da kapalı tutmayı öneriyor. PHP kılavuzu da yükleme ilerleme çubuğu kullanmayan uygulamalarda bu seçeneği kapatmayı öneriyor, çünkü oturuma yazılan dosya ve alan adları doğrulanmıyor. Sitenizde bir dosya yükleme ilerleme çubuğu çalışmayı bırakırsa nedeni bu ayardır.

Ondrej PPA ya da Docker php: imajı kullanıyorsanız

Ondrej PPA paketleri ve Docker Hub'daki resmi php imajları Ubuntu arşivinden farklı çalışır. Bunlar upstream sürüm numarasını taşır. Bu yüzden onlarda php -v gerçekten anlamlıdır. Çıktıdaki numarayı php.net listesiyle karşılaştırın: 8.5 serisinde en az 8.5.12, 8.4'te en az 8.4.27, 8.3'te en az 8.3.36, 8.2'de en az 8.2.35.

PPA kullanıyorsanız sudo apt update && sudo apt upgrade çalıştırın ve ardından numarayı kontrol edin. PPA'nın düzeltilmiş paketi yayımlayıp yayımlamadığını bu satırları yazarken doğrulayamadık, bu yüzden güncelleme sonrasında numarayı mutlaka kendiniz okuyun. Launchpad'deki PPA sayfası deponun packages.sury.org/php adresine taşındığını yazıyor. Ubuntu 26.04 (resolute) için asıl kaynak artık orası. 22.04 ve 24.04 için PPA hâlâ kullanılabiliyor. PPA üzerinden 8.1 ya da daha eski bir seri kullanıyorsanız, php.net'in uyarısı geçerli: bu seriler PHP projesinden güncelleme almıyor. Desteklenen bir seriye geçin. 8.2 serisi de php.net'e göre 31 Aralık 2026'da destek dışı kalacak.

Docker kullanıyorsanız kapsayıcının içindeki PHP'yi sorun:

docker compose exec SERVIS_ADI php -v

Numara eskiyse imajı yeniden çekin ya da yeniden derleyin. Kendi Dockerfile'ınız php: imajından türüyorsa:

docker compose build --pull
docker compose up -d

Hazır bir imajı doğrudan kullanıyorsanız docker compose pull ve ardından docker compose up -d yeterli. Etiketiniz eski bir yama sürümünü sabitliyorsa yeniden çekmek işe yaramaz, çünkü o etiket hep aynı sürümü gösterir. Etiketi düzeltilmiş bir sürüme yükseltin. Docker Hub'da 22 Ekim 2026'da php:8.3.36-zts-alpine3.23 gibi düzeltilmiş numaralı etiketler görünüyordu. Yığını güncellemeden önce verinizi yedeklemeyi atlamayın. Docker Compose yığınını yedekleyip güncelleme rehberi bu sırayı adım adım anlatıyor.

Paylaşımlı hosting ile VPS arasındaki fark

Türkiye'de pek çok site cPanel ya da Plesk kullanan paylaşımlı hostingte çalışıyor. Orada PHP'yi hosting firması yönetir ve yamayı da o kurar. Sizin yapabileceğiniz, firmanıza PHP2Shell için yama durumunu sormaktır. php.net, Linux dağıtımlarının ve LTS sağlayıcılarının yamaları önceden aldığını yazıyor ve kullanıcılara kendi sağlayıcılarına danışmalarını öneriyor.

VPS'te ise bu iş sizindir. Sağlayıcınız işletim sistemini kurar, içindeki paketleri sizin yerinize güncellemez. VPS'e kendiniz bir yönetim paneli kurduysanız bir şeye dikkat edin. Panel PHP'yi Ubuntu deposu dışından kurduysa, yukarıdaki dpkg-query kontrolü o PHP'yi görmez. Web isteklerine hangi PHP'nin cevap verdiğini systemctl list-units çıktısından bulun ve o PHP'nin kendi ikili dosyasına -v ile sürümünü sorun.

Yamalı olmak temiz olmak demek değil

Paket güncel ve servis yeniden başlamış olabilir. Bu, sunucunun bugünden sonra korunduğunu gösterir. Güncellemeden önce ne olduğunu göstermez. Amazon'un raporladığı istismar girişimi 17 Ekim 2026 tarihli, yani açık duyurulmadan önceye ait. Sunucunuz o tarihten bu yana açıktaysa geriye dönüp bakmanız gerekir.

İlk bakılacak yer, 17 Ekim'den sonra değişen PHP dosyalarıdır. SITE değişkenine sitenizin kök dizinini yazın:

SITE=/sitenizin/kok/dizini
sudo find "$SITE" -name '*.ph*' -newerct '2026-10-17' -printf '%CY-%Cm-%Cd %CH:%CM %p\n' | sort

-newerct dosyanın içeriğine değil, inode değişim zamanına (ctime) bakar. Bu tercih bilinçli. Saldırgan bir dosyanın değişiklik zamanını (mtime) touch ile geriye alabilir. ctime ise her değişiklikte çekirdek tarafından yazılır ve normal bir kullanıcı onu geriye çekemez. Bunun bir bedeli var: izin değiştirme ya da yedekten geri yükleme de ctime'ı günceller. Listede böyle meşru değişiklikler de göreceksiniz.

İkinci bakılacak yer, yükleme dizinleridir. WordPress'te wp-content/uploads, Laravel'de genellikle storage/app/public gibi dizinler kullanıcı dosyaları içindir. Orada çalıştırılabilir bir PHP dosyası beklenmez:

sudo find "$SITE" -path '*upload*' -name '*.ph*'

Bu komutun boş çıktısı temiz olduğunuzu kanıtlamaz, ama dolu bir çıktı hemen incelemeniz gereken bir şeydir. Bu iki find kontrolü genel bir güvenlik alışkanlığıdır. Amazon'un raporu bunları ayrıca istemiyor.

Amazon'un önerisi, form yüklemelerinde PHP_SESSION_UPLOAD_PROGRESS dizesini içeren POST isteklerini aramaktır. Standart erişim günlükleri isteğin gövdesini kaydetmez, bu yüzden bu dizeyi orada bulamazsınız. Bir WAF (web application firewall, web uygulama güvenlik duvarı) ya da istek gövdesini kaydeden bir günlüğünüz varsa orada arayın. Amazon ayrıca beklenmeyen süreç çalıştırmaya ve dosya değişikliklerine bakmayı öneriyor. Çalışan süreçleri başlama sırasıyla görün:

ps -eo user,pid,ppid,lstart,args --sort=start_time

PHP işçilerinin kullanıcısı altında çalışan ama PHP ya da web sunucusu olmayan bir süreç, örneğin bir kabuk ya da bir indirme aracı, ciddi bir işarettir. Böyle bir şey bulursanız sunucuyu temizlemeye çalışmadan önce VPS'iniz hacklendiğinde ilk saatte yapılacaklar rehberini okuyun. Sunucudaki diğer bilinen açıkları da tek seferde taramak isterseniz sunucunuzu bilinen CVE'lere karşı kontrol etme yazımız iyi bir sonraki adım.

Kişisel veri varsa: KVKK ve 72 saat

Sunucuda müşteri, üye ya da sipariş verisi gibi kişisel veriler varsa ve bir ihlal bulduysanız, teknik temizlik tek yükümlülüğünüz değildir. Kişisel Verileri Koruma Kurulu'nun 24.01.2019 tarihli 2019/10 sayılı kararı, veri sorumlusunun ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirmesini istiyor. Süre, ihlali öğrendiğiniz andan başlar, ihlalin gerçekleştiği andan değil.

Bildirim formu ve rehber kvkk.gov.tr adresindeki Veri İhlali Bildirimi sayfasında. Bu kararın sonradan değişip değişmediğini kontrol etmedik. Bildirim yapmadan önce kvkk.gov.tr üzerindeki güncel kuralları okuyun ve gerekiyorsa bir hukukçuya danışın.

FAQ

Ubuntu'da php -v neden yamadan sonra da eski sürümü gösteriyor?

Ubuntu güvenlik düzeltmelerini PHP'nin upstream sürüm numarasını değiştirmeden ekler. Değişen kısım paket sürümünün sonundaki Ubuntu ekidir, örneğin 24.04'te 8.3.6-0ubuntu0.24.04.13. Paketin tam sürümünü dpkg-query -W -f='${Package} ${Version}\n' 'php8.3*' ile okuyun ve Canonical'ın CVE sayfasındaki düzeltilmiş sürümle dpkg --compare-versions SURUM ge DUZELTME ile karşılaştırın. Komut 0 ile dönüyorsa paket yamalıdır.

Paketi güncelledim. PHP-FPM'i yeniden başlatmak gerçekten gerekli mi?

Evet, en azından kontrol etmeniz gerekir. apt upgrade diskteki dosyaları değiştirir, ama çalışan PHP-FPM işçileri ve mod_php yüklü Apache süreçleri başladıkları andaki eski kodla çalışmaya devam eder. systemctl show -p ActiveEnterTimestamp BIRIM_ADI ile servisin başlama zamanını, /var/log/dpkg.log ile güncelleme zamanını karşılaştırın. Servis güncellemeden önce başladıysa sudo systemctl restart BIRIM_ADI çalıştırın.

session.upload_progress.enabled=0 ayarı PHP2Shell'e karşı yeterli mi?

Hayır. php.net bu ayarı CVE-2026-109619 için geçici bir önlem olarak veriyor. Doğrulanmış oturum yollarını kapatır ama açığın diğer varyantlarını kapatmaz. Ayar php.ini, FPM havuzu ya da sunucu yapılandırmasında olmalı, ini_set() ya da .user.ini ile yapılmamalı. Ardından her işçi yeniden başlatılmalı. Tam çözüm yalnızca düzeltilmiş PHP paketini kurmaktır.

Ubuntu 20.04'te PHP 7.4 kullanıyorum. Yama alabilir miyim?

Ubuntu 20.04 için düzeltilmiş paket 7.4.3-4ubuntu2.29+esm5 yalnızca Ubuntu Pro üzerinden dağıtılıyor, yani Pro'suz bir sunucuda apt upgrade bu düzeltmeyi getirmez. Canonical, Pro'yu kişisel ve küçük ölçekli ticari kullanım için 5 makineye kadar ücretsiz sunuyor. Bir VPS'in kapsama girip girmediğini ubuntu.com/pro üzerindeki güncel şartlardan kontrol edin. Uzun vadede desteklenen bir Ubuntu sürümüne ve PHP serisine geçmek gerekir.

Sunucumu yamaladım. Saldırıya uğrayıp uğramadığımı nasıl anlarım?

Yama, güncellemeden önce olanları geri almaz. Amazon, açığın duyurulmasından dört gün önce, 17 Ekim 2026'da bir istismar girişimi gördüğünü bildirdi. Bu tarihten sonra değişen PHP dosyalarını find SITE_DIZINI -name '*.ph*' -newerct '2026-10-17' ile, yükleme dizinlerindeki PHP dosyalarını ayrıca arayın. PHP kullanıcısı altında çalışan beklenmeyen süreçlere ps ile bakın. Sunucuda kişisel veri varsa ve bir ihlal bulursanız, KVKK Kurulu'nun 2019/10 sayılı kararı ihlali öğrendiğiniz andan itibaren en geç 72 saat içinde Kurul'a bildirmenizi istiyor.