PHP2Shell yama günü: PHP, Node.js, CloudLinux ve cPanel sunucuları için uygulama rehberi

21 Ekim 2026, PHP çalıştıran neredeyse her sunucu için bir yama günüydü. PHP projesi artık PHP2Shell olarak bilinen iki kritik açık için acil düzeltmeler yayımladı, Node.js birkaç saat arayla kendi güvenlik sürümünü çıkardı ve düzeltmeleri geriye taşınmış EasyApache 4 paketleri aynı öğleden sonra cPanel ve CloudLinux sunucularına ulaştı. Bu yazı, uygulamayı yazan değil altyapıyı işleten herkes için, bizim kullandığımız uygulama rehberi.

PHP2Shell neden farklı

CVE-2026-109618 ve CVE-2026-109619’un ikisi de CVSS v4.0’da 9.2 puan aldı ve ayrıntılar bu puanı açıklıyor. Birincisi bir bellek yetersizliği hatası: PHP, istek verisi yarı yarıya hazırlanmışken kesintiye uğrayabiliyor ve ardından gelen temizlik bozuk veriyi geçerliymiş gibi işliyor. İkincisi bayat genel durum (stale global state): bir isteğe ait veri, belleği serbest bırakıldıktan sonra da yaşamaya devam ediyor ve aynı işçideki bir sonraki istek, başlatma onu sıfırlamadan önce bu veriyi kullanıyor.

Üç özellik bunu bir uygulama sorunu değil, barındırma sorunu yapıyor. Giriş yapmak gerekmiyor. Saldırı, uygulama kodu çalışmadan önce, istek ayrıştırılırken gerçekleşiyor; yani sıkılaştırılmış bir WordPress ya da katı bir framework işe yaramıyor. Ve her web SAPI’si etkileniyor: PHP-FPM, mod_php’li Apache, php-cgi, LiteSpeed ve FrankenPHP; en yüksek risk mod_php’de. Ayrıntılar planlanan açıklama tarihinden önce sızdı, çalışan bir istismar gösterildi ve Cloudflare bilinen saldırı yolları için tüm planlarda WAF kuralları devreye aldı. Birleşik Krallık NCSC, yamalanamayan sistemlerin çevrim dışı alınmasını öneriyor. Aktif olarak istismar ediliyormuş gibi davranın.

21 Ekim’de neler yamalandı

Node.js sürümünün etki alanı daha dar ama ciddiyeti daha az değil. CVE-2026-111497, üç hatta da Brotli çözücüsünde sınır dışı yazma hatası; CVE-2026-106069 ve CVE-2026-105483, gevşek ayrıştırılan ya da tam genişlikli (fullwidth) yazılmış IP adresleri üzerinden TLS ana bilgisayar adı doğrulamasını atlatıyor; CVE-2026-105482 ise dns.resolve içinde adları NUL karakterinde kesiyor. Gömülü c-ares, OpenSSL ve Undici güncellendi, sertifika deposundan da ele geçirilen bir eMudhra ara sertifikası çıkarıldı.

Bir derlemeyi düzeltilmiş sürümlerle karşılaştırın:

Hangi PHP kurulumları en açık durumda?

PHP’yi web üzerinden sunmanın her yolu etkileniyor, ancak duyuru en yüksek riski mod_php’ye veriyor; güncellemeden sonra her kurulumun nasıl yeniden başlatıldığı da eski kodun ne kadar süre çalışmaya devam edeceğini belirliyor. Aşağıdaki tablo, yeniden başlatmaları planlarken kullandığımız sürüm.

Paylaşımlı bir sunucu çoğu zaman bunların birkaçını bir arada barındırır. Karma bir sunucuda CGI ile sunulan siteler yamalı ikili dosyayı bir sonraki istekte alırken FPM havuzları yeniden başlayana kadar eskisini kullanmaya devam eder; aşağıdaki bayat süreç kontrolünün önemli olmasının nedeni bu farktır.

Bir cPanel ve CloudLinux sunucusundan saha notu

cPanel 11.138 çalıştıran CloudLinux 8 sunucularımızdan birinde EasyApache 4 güncellemeleri 21 Ekim’de sunucu saatiyle 16:16’da kendiliğinden kuruldu ve 7.2’den 8.5’e kadar her ea-php sürümünü kapsadı. İki ayrıntı önemli. Birincisi, düzeltme geriye taşındığı için php -v hâlâ 8.4.26 gösteriyordu; kanıt paket değişiklik günlüğünde, her derleme CVE-2026-109618 ve CVE-2026-109619’u listeliyor. İkincisi, her PHP süreci yeniden başlayana kadar güncelleme işin yalnızca yarısı; bunu varsaymak yerine kontrol etmek gerekiyor.

Yamadan önce: güvenle zaman kazanın

1. Her PHP ikili dosyasını listeleyin. ea-php, alt-php, dağıtım PHP’si, LiteSpeed lsphp, Docker imajları ve bir uygulamayla birlikte gelen her şey. Her biri ayrı bir yama demek.
2. Güvenli olduğu yerde upload progress’i kapatın. php.ini içinde ya da FPM havuzunda php_admin_value ile session.upload_progress.enabled = 0 yapın, ardından işçileri yeniden başlatın. Bu yalnızca CVE-2026-109619’un doğrulanmış oturum yolunu kapatır; ini_set() ve .user.ini çok geç devreye girer.
3. memory_limit = -1 ayarını kaldırın. Sınırsız bellek, CVE-2026-109618’in bellek yetersizliği yoluna ulaşmayı kolaylaştırır.
4. WAF korumasını açın. Imunify360 8.83 kural seti, Apache’de bilinen istismar biçimini engelliyor; Cloudflare’in de yönetilen kuralları var. İkisi de geçici ve LiteSpeed’de Imunify360 kuralı yalnızca kayıt tutuyor.
5. Bir referans durumu alın. Son değiştirilen PHP dosyalarını ve mevcut çökme sayılarını kaydedin ki yamadan sonra karşılaştırabilesiniz.

Yamadan sonra: kanıtlayın

1. Sürüm numarasıyla değil, değişiklik günlüğüyle doğrulayın. cPanel’de rpm -q --changelog ea-php84-php-cli | head iki CVE’yi de göstermeli. php.net derlemelerinde 8.2.35, 8.3.36, 8.4.27 ya da 8.5.12 olup olmadığına bakın.
2. PHP yüklemiş her şeyi yeniden başlatın. PHP-FPM’i yeniden başlatın; mod_php için graceful yeniden yükleme yetmez, Apache’yi tamamen yeniden başlatın; LiteSpeed’de lsphp süreçlerini sonlandırın; kuyruk işçilerini ve uzun süre çalışan servisleri yeniden başlatın.
3. Bayat süreçleri arayın. grep -lE '/opt/cpanel/ea-php.*\(deleted\)$' /proc/[0-9]*/maps hiçbir şey döndürmemeli. Her eşleşme, hâlâ açıklı kodu çalıştıran bir süreç demek.
4. Node.js’i aynı gün güncelleyin. Her servisi, konteyneri ve CI çalıştırıcısını 22.23.4, 24.22.1 ya da 26.12.1’e taşıyın; artık düzeltme almayan Node.js 20’yi emekliye ayırın.
5. Önce tarayın, sonra önlemleri gevşetin. Geçici WAF kurallarını kaldırmadan ve eski ayarlarınızı geri yüklemeden önce yeni ya da değişmiş PHP dosyalarını, web shell’leri ve beklenmedik cron girdilerini referans durumla karşılaştırın.
6. Sürüm geçişlerini planlayın. PHP 8.1 ve öncesi satıcıların geriye taşıdığı yamalara bağlı; PHP 8.2 de 31 Aralık 2026’da ömrünü tamamlıyor. Hedef olarak 8.4 ya da 8.5 seçin.

Güncelleme bir sunucu filosuna nasıl yayılır?

Tek bir sunucuda güncelleme, bir paket kurulumu ve bir yeniden başlatmadan ibaret. Bir filoda ise risk hatadan dağıtımın kendisine kayar: bir makinede sorunsuz çalışan bir yapılandırma başka bir makinedeki siteyi bozabilir, yanlış anda yapılan bir yeniden başlatma da istekleri düşürür. Biz her seferinde aynı sırayı izliyoruz.

1. Bir kanarya sunucu seçin. Temsili bir site karışımı taşıyan tek bir sunucuyu yamalayın, yeniden başlatın ve kontrol panelini ve örnek siteleri öncesi ve sonrasıyla karşılaştırın.
2. Önceki durumu kaydedin. Her sunucu için kurulu paket sürümleri, her örnek sitenin kullandığı işleyici ve HTTP durum kodu. Bu olmadan bir gerilemeyi eski bir arızadan ayırt edemezsiniz.
3. Sakin bir saatte yeniden başlatın. FPM’i yeniden başlatmak kısa sürer, ancak mod_php için Apache’nin tamamen yeniden başlatılması o an süren bağlantıları düşürür.
4. Doğrulayın, sonra ilerleyin. Değişiklik günlüğü kontrolü, bayat süreç kontrolü, örnek siteler, ardından sıradaki sunucu. Bir hata, nedeni anlaşılana kadar dağıtımı durdurur.

EasyApache 4 otomatik güncellemeleri açık olan cPanel sunucularında kurulum adımı, bizdeki gibi kendiliğinden gerçekleşir; geriye iş olarak yeniden başlatma ve doğrulama kalır. Otomatik güncellemesi olmayan sunucularda kurulum adımının ayrıca planlanması gerekir ve unutulma ihtimali en yüksek olanlar da bunlardır.

Yamadan sonra hangi işaretlere bakmalısınız?

Yama açığı kapatır, ama birinin ondan önce açığı kullanıp kullanmadığını söylemez. Ayrıntılar sürümden önce sızdığı için güncellemenizden önceki günleri kısaca gözden geçirmeye değer. Ekim ortasından bu yana web kök dizinlerinde oluşturulmuş ya da değiştirilmiş ve hiçbir dağıtımla açıklanamayan PHP dosyalarına, bir sinyalle sonlanan işçilerden söz eden PHP-FPM günlük satırlarına, açıklanamayan 500 ya da 502 yanıt patlamalarına, web kullanıcıları için yeni cron girdilerine ve PHP süreçlerinden tanıdık olmayan sunuculara giden bağlantılara bakın.

Bunların hiçbiri tek başına bir sızmayı kanıtlamaz ve temiz bir sonuç da garanti değildir. Bir bulguyu bir incelemenin başlangıcı olarak ele alın, yamadan önce aldığınız referans durumla karşılaştırın ve inceleme bitene kadar geçici WAF kurallarını yerinde tutun.

2026’nın daha önceki sürümlerinin arka planı için PHP ve Node.js sürümlerine genel bakış yazısına bakın; aynı haftanın BIND ve Java güncellemeleri tek haftada Node.js, BIND ve Java yazısında, çekirdek tarafı ise paylaşımlı bir Linux sunucu için beş çekirdek ayarı yazısında.

SSS: PHP2Shell ve 21 Ekim 2026 güncellemeleri

PHP2Shell nedir ve Ekim 2026’da neden acil olarak yamalandı?

PHP2Shell, PHP’de CVSS v4.0’da 9.2 puan alan iki bellek güvenliği hatası olan CVE-2026-109618 ve CVE-2026-109619’a verilen ad. Giriş gerektirmiyorlar ve uygulama kodu çalışmadan önce devreye giriyorlar. Ayrıntılar planlanan tarihten önce sızdığı için PHP düzeltmeleri 21 Ekim 2026’da yayımladı.

Hangi PHP sürümleri PHP2Shell’i düzeltiyor, PHP 8.1 ve öncesi ne olacak?

Ana projede düzeltilmiş sürümler 8.2.35, 8.3.36, 8.4.27 ve 8.5.12. PHP 8.1 ve öncesi için ana projeden yeni sürüm çıkmıyor; PHP ekibi 7.4, 8.0 ve 8.1 için küçük kaynak kod yamaları yayımladı ve bazı satıcılar kendi yamalı paketlerini dağıtıyor.

cPanel PHP2Shell düzeltmesini kurduktan sonra php -v neden hâlâ eski sürümü gösteriyor?

Çünkü EasyApache 4 düzeltmeyi yeni bir PHP sürümü olarak değil, yeni bir paket eki taşıyan geriye taşınmış bir yama olarak dağıttı. Her ea-php paketinin değişiklik günlüğü iki CVE’yi de listeliyor ve kanıt php -v değil, bu değişiklik günlüğü.

mod_php mı PHP-FPM mi: hangisi PHP2Shell’e karşı daha açık durumda?

PHP duyurusu en yüksek riski, karşısında çalışan bir istismar gösterilmiş olan mod_php’ye veriyor. PHP-FPM de etkileniyor. Ne çalıştırırsanız çalıştırın, düzeltme ancak doğru yeniden başlatmadan sonra geçerli olur: mod_php için Apache’nin tamamen yeniden başlatılması, havuzlar için FPM’in yeniden başlatılması.

session.upload_progress’i kapatmak, yama yapmadan PHP2Shell’i hafifletmek için yeterli mi?

Hayır. Yalnızca CVE-2026-109619’un doğrulanmış oturum yolunu kapatır, CVE-2026-109618 için hiçbir şey yapmaz. Bunu ini_set() ile değil, php.ini içinde ya da FPM havuzunda ayarlayın ve güncelleme kurulana kadar geçici bir önlem olarak görün.

Imunify360 kuralı 2026’da LiteSpeed sunucularını PHP2Shell’e karşı koruyor mu?

Yalnızca kısmen. Imunify360 8.83 kural seti Apache’de bilinen istismar biçimini engelliyor, ancak LiteSpeed’de bu kalıbı engellemek yerine yalnızca kaydediyor. Her iki sunucuda da bu geçici bir koruma, yamalı PHP’nin yerini tutmuyor.

Güncellemeden sonra hiçbir sürecin hâlâ yamasız PHP kodu çalıştırmadığını nasıl doğrularsınız?

Bellek eşlemelerinde silinmiş PHP kütüphanelerini arayın: grep -lE '/opt/cpanel/ea-php.*\(deleted\)$' /proc/[0-9]*/maps. Boş sonuç, çalışan her sürecin yeni dosyaları yüklediği anlamına gelir; her eşleşme hâlâ yeniden başlatılması gereken bir süreçtir.

CloudLinux alt-php paketleri PHP2Shell için yamalandı mı, yoksa yalnızca EasyApache ea-php mi?

ea-php yamaları 21 Ekim’de CloudLinux 8 sunucularına ulaştı. CloudLinux, alt-php paketlerinin işletim sistemine göre kademeli olarak dağıtılacağını duyurdu ve durumlarını durum sayfasında listeledi; hesaplarınızın kullandığı alt-php sürümleri için o sayfayı kontrol edin.

Önce PHP mi Node.js mi yamalanmalı: 21 Ekim 2026 Node.js sürümü PHP2Shell’i beklemeli mi?

Hayır, ikisini paralel yürütün. Node.js sürümü, aralarında uzaktan kod çalıştırmaya izin veren bir Brotli çözücü hatasının da bulunduğu dört yüksek önem dereceli sorunu düzeltti. Node.js’i güncellemek PHP’ye dokunmaz, dolayısıyla birini diğerinin arkasında bekletmek için bir neden yok.

Bir sunucunun PHP2Shell yamasından önce ele geçirilip geçirilmediğini nasıl anlayabilirsiniz?

Tek bir test yok. Web kök dizinlerinde açıklanamayan yeni PHP dosyalarını, FPM günlüklerinde çöken işçileri, olağandışı 500 ya da 502 patlamalarını, yeni cron girdilerini ve PHP’den dışarı giden bağlantıları inceleyin ve bunları bir referans durumla karşılaştırın. Bir bulgu bir incelemeyi başlatır; temiz bir sonuç ise kanıt değil, yalnızca içinizi rahatlatır.

Kaynaklar

• PHP güvenlik sürümü, 21 Ekim 2026, php.net
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618) ve GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), GitHub
• Ekim 2026 güvenlik sürümleri, nodejs.org
• PHP2Shell: kritik PHP açıkları yamalandı, Help Net Security
• PHP2Shell için Imunify360 8.83 kural seti, Imunify360