Merhabalar yine gündemi baya meşgul eden bir PHP açığıyla karşınızdayım. 20 Ekim’de detayları planlanandan önce sızdırılan ve PHP2Shell adı verilen CVE-2026-109618 ve CVE-2026-109619 açıkları için PHP ekibi 21 Ekim’de acil yama yayınladı. Açık duyurulur duyurulmaz ben de yönettiğim sunucuları güncelledim ve bu yazıda PHP2Shell HestiaCP sunucuda nasıl fixlenir adım adım anlatacağım.
cPanel / WHM kullanıyorsanız orada işler biraz daha farklı, onun için ayrıca yazdığım PHP2Shell cPanel Fix: CVE-2026-109618 ve CVE-2026-109619 yazıma göz atabilirsiniz.
PHP2Shell (CVE-2026-109618 / CVE-2026-109619) Nedir?
PHP2Shell, Ekim 2026’da ortaya çıkan ve CVE-2026-109618 ile CVE-2026-109619 numaralarını alan iki kritik PHP çekirdek açığına verilen isimdir. PHP ekibi açıkları CVSS v4.0 üzerinden 9.2 puanla değerlendirdi. Açıklar, kimlik doğrulaması gerektirmeden saldırganın sunucu üzerinde uzaktan kod çalıştırmasına (RCE) imkan tanıyabiliyor. Açıkları Wiz ve OpenAI araştırmacıları bildirdi; Wiz’in açıklamasına göre PHP 5.4’ten PHP 8’e kadar çok geniş bir sürüm aralığı etkileniyor. Sadece belirli bir yapılandırma değil, web isteğine cevap veren PHP-FPM, Apache mod_php, php-cgi, LiteSpeed gibi neredeyse tüm PHP kurulumları risk altında.
Açığın kapatıldığı resmi PHP sürümleri şunlar:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Ömrünü doldurmuş (EOL) 7.4, 8.0, 8.1 gibi sürümler için resmi bir sürüm çıkmadı fakat PHP güvenlik ekibi bu sürümler için de kaynak kod yamalarını paylaştı. HestiaCP’nin kullandığı Ondřej Surý deposu (packages.sury.org) bu yamaları eski sürümlere de taşıdı, yani 7.4 kullanıyorsanız bile güncelleme alabiliyorsunuz.
Saldırı tarafına gelirsek; Amazon, Cloudflare ve watchTowr gibi firmalar açığın aktif olarak istismar edilmeye çalışıldığını raporladı. Yani bu güncellemeyi “sonra yaparım” diye bekletmeyin.
PHP2Shell HestiaCP Sunucuda Nasıl Fixlenir?
HestiaCP, sitelerin PHP sürümlerini Sury deposundan kuruyor. Ayrıca panelin kendisi de hestia-php adında ayrı bir PHP ile çalışıyor. İkisini de güncellememiz gerekiyor. Ben işlemleri Ubuntu 24.04 üzerinde yaptım, Debian’da da komutlar aynı.
1) Sunucuda Hangi PHP Sürümleri Var?
Öncelikle sunucumuzda hangi PHP sürümlerinin kurulu olduğuna bakalım.
dpkg -l | grep -E "^ii\s+php[0-9.]+-(fpm|common) " | awk '{print $2, $3}'
Benim sunucumda 7.4, 8.1, 8.2, 8.3 ve 8.5 kuruluydu. Burada dikkat etmeniz gereken nokta php -v çıktısına bakarak karar vermemek; çünkü 7.4 gibi eski sürümlerde yama gelse de sürüm numarası hala 7.4.33 görünüyor. Kontrolü aşağıda paket notlarından yapacağız.
2) Paket Listesini Güncelleme
apt update apt list --upgradable 2>/dev/null | grep -E "^(php|hestia-php)"
Listede php7.4, php8.x ve hestia-php paketlerini görüyorsanız güncelleme gelmiş demektir.
3) Sadece PHP Paketlerini Güncelleme
Ben sunucudaki diğer paketlere dokunmadan sadece PHP paketlerini güncelledim. Aşağıdaki komut güncellenebilir listesindeki php ve hestia-php paketlerini bulup sadece onları yükseltiyor.
apt install --only-upgrade -y $(apt list --upgradable 2>/dev/null | grep -E "^(php|hestia-php)" | cut -d/ -f1)
Dilerseniz tüm sistemi de apt upgrade ile güncelleyebilirsiniz ama canlı sunucuda ben önce kritik olanı yapıp diğerlerini sonraya bırakmayı tercih ediyorum.
4) Yamanın Gerçekten Geldiğini Doğrulama
Şimdi asıl önemli kısma geldik. Her PHP sürümünün paket notlarında (changelog) CVE numarası geçiyor mu kontrol ediyoruz.
for v in 7.4 8.1 8.2 8.3 8.5; do echo -n "php$v: " zcat /usr/share/doc/php$v-common/changelog.Debian.gz 2>/dev/null | head -60 | grep -q 109618 && echo "YAMALI" || echo "KONTROL ET" done
Kendi sunucunuzda olmayan sürümleri listeden çıkartabilirsiniz. Hepsinde “YAMALI” yazıyorsa bu adım tamam.
5) PHP-FPM ve Hestia Servislerini Yeniden Başlatma
Paketleri güncellemek tek başına yetmiyor, çalışan PHP-FPM süreçleri hala eski dosyayı kullanıyor olabilir. Bu yüzden servisleri yeniden başlatıyoruz.
for v in 7.4 8.1 8.2 8.3 8.5; do systemctl is-active --quiet php$v-fpm && systemctl restart php$v-fpm && echo "php$v-fpm yeniden başlatıldı" done systemctl restart hestia
Son olarak eski PHP dosyasıyla çalışmaya devam eden bir süreç kalmış mı kontrol ediyoruz. Çıktı 0 ise her şey yolunda.
for p in $(pgrep -f php); do ls -l /proc/$p/exe 2>/dev/null; done | grep -c deleted
Güncelleme Gelmediyse Geçici Önlem
Herhangi bir sebepten güncelleme alamıyorsanız Huntress’in yamasız sürümler için önerdiği geçici önlem session.upload_progress.enabled ayarını kapatmak. Bu kalıcı bir çözüm değil, sadece yama gelene kadar riski azaltmak için. Örnek olarak PHP 8.3 için:
echo "session.upload_progress.enabled = Off" > /etc/php/8.3/fpm/conf.d/99-php2shell.ini systemctl restart php8.3-fpm
Yama geldikten sonra bu dosyayı silmeyi unutmayın.
Ekstra: Sitelerinizi de Kontrol Edin
Açık yama çıkmadan önce sızdırıldığı için güncellemeden sonra sitelerinize de bir göz atmanızı tavsiye ederim. Ben şu kontrolleri yaptım:
# Son günlerde değişmiş PHP dosyaları find /home/*/web/*/public_html -type f -name "*.php" -newermt "2026-10-15" | grep -v /cache/ # uploads klasöründe olmaması gereken PHP dosyaları find /home/*/web/*/public_html -path "*/uploads/*" -name "*.php" ! -name index.php # WordPress çekirdek dosyaları orijinal mi? sudo -u KULLANICI wp --path=/home/KULLANICI/web/SITE/public_html core verify-checksums
WordPress kullanıyorsanız admin kullanıcılarınızı da kontrol edin, tanımadığınız bir yönetici hesabı varsa hemen müdahale edin. Güzel bir not olarak HestiaCP her siteye varsayılan olarak open_basedir ve disable_functions tanımlıyor, bu da bir site ele geçirilse bile saldırganın diğer sitelere ve sistem komutlarına erişmesini zorlaştırıyor. Bu ayarları kapattıysanız tekrar açmanızı öneririm.
Bu yazımızda PHP2Shell HestiaCP sunucuda nasıl fixlenir adım adım gördük. Umarım işinize yaramıştır, takıldığınız bir yer olursa yorumlarda yazabilirsiniz 🙂
