PHP Kritik RCE Zafiyeti (CVE-2026-109618) ve Güncelleme Rehberi

Merhabalar gün geçmiyor ki yeni bir açık, yenir bir cyber tehdit çıkmasın ama çıkıyor maalesef. Gerçi bu tip saldırılar olmasa ilgili güvenlik güncellemeleri de olmayacağı için kontrollü çalışmak iyidir diyorum ve Eğer kendi sunucunuzu yönetiyorsanız veya müşterileriniz için hosting altyapısı sağlıyorsanız, elinizdeki işi bırakıp terminali açmanız gereken o günlerden birindeyiz.

PHP ekibi ve Wordfence bugün (21 Ekim 2026) oldukça kritik bir güvenlik bülteni yayınladı. Doğrudan PHP çekirdeğini hedef alan CVE-2026-109618 ve CVE-2026-109619 kodlu iki yeni zafiyet, herhangi bir kimlik doğrulamasına ihtiyaç duymadan uzaktan kod çalıştırılmasına (Unauthenticated RCE) olanak tanıyor. CVSS v4.0 ölçeğine göre 9.2 (Kritik) olarak derecelendirilen bu açıklar, saldırganların sunucunuza tek bir özel HTTP isteği göndererek doğrudan sistemde komut çalıştırabilmesi anlamına geliyor.

İşin en tehlikeli ve genelde gözden kaçan kısmı şu: Bu bir WordPress çekirdek, tema veya eklenti açığı değil. Doğrudan PHP’nin kendisinde bulunan bir zafiyet. Dolayısıyla "WordPress otomatik güncellemelerim açık, güvendeyim" diyebileceğiniz bir senaryo yok. Müdahaleyi bizzat sunucu seviyesinde, işletim sistemi paketlerinde yapmak zorundasınız.

Kimler Risk Altında ve Teknik Detaylar Neler?

PHP güvenlik ekibinin paylaştığı bilgilere göre, web isteklerini karşılayan hemen hemen tüm PHP çalışma modları bu durumdan etkileniyor:

• Apache (mod_php)

• PHP-FPM (Nginx veya Apache arkasında çalışan yapılar)

• LiteSpeed / OpenLiteSpeed (lsphp)

• php-cgi ve FrankenPHP

Özellikle Apache üzerinde mod_php kullanan geleneksel yapılarda risk en üst seviyede. PHP ekibi, bu kurulumlarda daha uygulama kodunuz (örneğin WordPress'in index.php dosyası veya güvenlik eklentiniz) devreye bile girmeden, gönderilen ilk istekle istismarın tetiklenebildiğini doğruladı.

Geçmeniz Gereken Güvenli Sürümler

PHP ekibi aktif destek verdiği tüm dallar için yamalı sürümleri hızla yayınladı. Sunucunuzdaki PHP versiyonlarının en az aşağıdaki sürümlerde olduğundan emin olmalısınız:

PHP Dalı	Yamalı (Güvenli) Sürüm	Durum Notu
PHP 8.5	8.5.12	Aktif destekleniyor
PHP 8.4	8.4.27	Aktif destekleniyor
PHP 8.3	8.3.36	Aktif destekleniyor
PHP 8.2	8.2.35	31 Aralık 2026'da ömrü (EOL) bitiyor

Eski Sürümler (PHP 7.4, 8.0 ve 8.1) Ne Olacak?

Resmi olarak PHP 8.1 ve altı artık PHP projesinden güncelleme almıyor. Ancak kurumsal Linux dağıtımları (Ubuntu LTS, Debian, AlmaLinux, Rocky Linux) kendi depolarındaki paketlere bu yamaları backport ediyorlar. Eğer özel bir derleme kullanıyorsanız, PHP güvenlik ekibi GitHub üzerinden PHP-7.4, PHP-8.0 ve PHP-8.1 için de acil durum kaynak kodu yamalarını (source backports) yayınladı.

Kontrol Panellerinde ve Sunucularda PHP Nasıl Güncellenir?

Birçok sistem yöneticisi standart paket yöneticileri yerine kontrol panellerinin kendi izole PHP derlemelerini kullanıyor. Aşağıda en sık kullanılan mimariler için doğrudan uygulayabileceğiniz güncelleme adımlarını derledim.

(Not: İşlemlere başlamadan önce kritik konfigürasyonlarınızın veya sunucunuzun anlık görüntüsünü -snapshot- almayı ihmal etmeyin).

1. CyberPanel / OpenLiteSpeed (lsphp) Güncellemesi

CyberPanel ve OpenLiteSpeed mimarilerinde PHP, standart sistem paketlerinden bağımsız olarak LiteSpeed’in kendi deposundan (lsphp) çalışır. Panel arayüzünde "CyberPanel Güncelle" demek çoğu zaman alt katmandaki lsphp binary'lerini güncellemez; bu işi SSH üzerinden paket yöneticisiyle yapmak en temiz yoldur.

sudo apt update sudo apt --only-upgrade install "lsphp*" -y

AlmaLinux / Rocky / RHEL tabanlı sistemlerde:

sudo dnf clean all sudo dnf update "lsphp*" -y

RHEL tabanlı dağıtımlarda ek paketler için Remi deposu (remirepo) kullanıyorsanız küçük bir parantez açayım: İlk duyuru anında Remi deposunda yamalar henüz imzalanmamıştı ancak PHP Vakfı kısa süre önce paketlerin imzalanıp depoya sürüldüğünü doğruladı. dnf clean all yapmadan güncellemeyi denerseniz önbellekten dolayı eski sürümü görmeye devam edebilirsiniz.

Güncelleme bittikten sonra OpenLiteSpeed'i ve çalışan lsphp süreçlerini sıfırlayarak yeni binary'lerin belleğe alındığından emin olun:

sudo systemctl restart lsws sudo killall -9 lsphp

2. cPanel / WHM (EasyApache 4)

cPanel tarafında EasyApache 4 paketleri işletim sisteminin paket yöneticisiyle entegre çalışır. WHM arayüzüne girip System Update menüsünden yapabileceğiniz gibi, doğrudan terminalden çok daha hızlı şekilde geçebilirsiniz:

`yum clean all && yum update "ea-php*" -y

AlmaLinux 8/9 kullanıyorsanız:

dnf clean all && dnf update "ea-php*" -y`

İşlem sonrasında PHP-FPM servislerini yeniden başlatmayı unutmayın:

/scripts/restartsrv_apache_php_fpm

3. Plesk Panel

Plesk, kendi barındırdığı plesk-php paketlerini kullanır. Sunucuya SSH ile bağlanıp standart sistem güncellemesini çalıştırdığınızda Plesk depolarından yeni PHP yamaları çekilecektir:

`# Ubuntu / Debian sudo apt update && sudo apt upgrade -y

AlmaLinux / RHEL

sudo dnf update -y`

Alternatif olarak Plesk arayüzünden Tools & Settings > Updates ekranına giderek bileşen güncellemelerini tetikleyebilirsiniz.

4. Panalsiz (Vanilla) Linux Sunucular (Ondřej Surý PPA / Remi)

Herhangi bir panel kullanmadan doğrudan Nginx veya Apache + PHP-FPM koşturduğunuz sunucularda (özellikle Ubuntu üzerinde ppa:ondrej/php kullanıyorsanız) standart güncelleme komutu yeterli olacaktır:

sudo apt update && sudo apt upgrade -y

Güncelleme tamamlandıktan sonra aktif PHP-FPM servisinizi mutlaka yeniden başlatın (aksi takdirde çalışan worker'lar RAM'deki eski zafiyetli kütüphaneyi kullanmaya devam eder):

# Kullandığınız sürüme göre değiştirin: sudo systemctl restart php8.3-fpm

Güncelleme Sonrası Kontrol: Sürüm Numarası Yanıltabilir!

Güncellemeyi yaptınız, terminale php -v yazdınız veya WordPress panelinden Araçlar > Site Sağlığı > Bilgi > Sunucu sekmesine baktınız ama sürüm numarasının 8.3.36 yerine hala daha eski bir alt sürüm göründüğünü fark ettiniz. Panik yapmayın.

Ubuntu ve Debian gibi dağıtımlar, kararlılığı bozmamak adına yeni PHP sürümünü komple çekmek yerine sadece güvenlik yamasını mevcut paketin içine entegre ederler (backporting). Bu durumda ana sürüm numarası değişmez, sadece paket sonundaki derleme kodu (örneğin ubuntu0.24.04.2) değişir.

Yamanın gerçekten uygulanıp uygulanmadığını teyit etmek için terminalden paketin değişiklik günlüğünü (changelog) sorgulayabilirsiniz:

Ubuntu / Debian için:

apt changelog php8.3-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"

AlmaLinux / Rocky / RHEL için:

rpm -q --changelog php-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"

(LiteSpeed kullanıyorsanız paket adı yerine lsphp83 gibi kendi paket adınızı yazabilirsiniz). Çıktıda ilgili CVE kodlarını görüyorsanız sunucunuz güvende demektir.

Genelde Unauthenticated RCE zafiyetleri, yayınlandıktan sonraki ilk 24-48 saat içinde otomatik tarama botlarının (scanner) hedefi haline gelir. Özellikle sunucunuzda çok sayıda site barındırıyorsanız veya paylaşımlı bir ortam yönetiyorsanız, bu güncellemeyi hafta sonuna bırakmadan bu gece aradan çıkarmanızı şiddetle tavsiye ederim.

Güncelleme sürecinde takıldığınız bir nokta veya özel bir mimari sorunuz olursa bana yazabilirsiniz. Güvenli ve kesintisiz günler dilerim!