2026’da PHP ve Node.js: güvenlik sürümleri ve sunucularınızda yapmanız gerekenler

Çoğu üretim ortamında PHP ve Node.js yan yana çalışır: PHP içerik yönetimi, faturalama ya da panel tarafında, Node.js ise API, derleme hattı ya da gerçek zamanlı servislerde. İki çalışma ortamı da 2026’da yüksek önem dereceli güvenlik sürümleri yayımladı ve onları barındıran sunucuların aynı anda iki cephede ilgi görmesi gerekiyor.

Bu yazı her projenin haziran ile eylül arasında neleri düzelttiğini, kullandığınız sürüm hattının neden tek bir yamadan daha önemli olduğunu, bir cPanel sunucusunda bir sitenin gerçekte hangi PHP’yi çalıştırdığını nasıl öğreneceğinizi ve sekiz adımlık bir kontrol listesini ele alıyor. 21 Ekim’deki acil PHP2Shell sürümünün kendine ait bir yama günü rehberi var.

PHP eylül 2026’da neleri düzeltti?

PHP projesi 24 Eylül 2026’da 8.2.34, 8.3.35, 8.4.26 ve 8.5.11 sürümlerini yaklaşık bir düzine CVE’yi kapsayan ortak bir güvenlik güncellemesi olarak yayımladı. Herkese açık bir web sunucusuna en kolay ulaşabilecek açık CVE-2026-91765: SOAP eklentisindeki sınırsız özyineleme, kimlik doğrulaması olmayan bir isteğin dışa açık bir SoapServer uç noktasını çökertmesine izin veriyor. CVE-2026-91766 ise uzak API çağıran her uygulamayı ilgilendiriyor: HTTP stream wrapper başka bir sunucuya yönlendirmeyi izlediğinde, ilk sunucu için verilen kimlik bilgileri de onunla birlikte gidebiliyordu.

İki TLS düzeltmesi, CVE-2026-91769 ve CVE-2026-91767, SAN uyuşmazlığından sonra ana bilgisayar adı doğrulamasının sertifikadaki CN alanına geri düşmesini engelliyor ve özel hazırlanmış joker karakterli adlardaki bir heap taşmasını kapatıyor. Sunucu tarafında, PHP-FPM’i bir IPv6 TCP soketinde çalıştırıyorsanız önce CVE-2026-91768’e bakın, çünkü listen.allowed_clients adresin yalnızca bir kısmını karşılaştırıyordu ve atlatılabiliyordu. Phar arşivleri de TAR başlığı ayrıştırmasındaki bir tamsayı taşması olan ve arşive sahte girdi eklenmesine izin veren CVE-2026-6103 için düzeltme aldı.

Node.js haziran ve temmuz 2026’da neleri düzeltti?

Node.js kısa aralıkla iki güvenlik sürümü çıkardı. Haziran sürümü (v22.23.0, v24.17.0, v26.3.1) on iki sorunu kapattı; aralarında, Unicode nokta karakterlerinin tutarsız işlenmesinden kaynaklanan ve joker sertifika derinliği kontrolünü atlatan bir kimlik doğrulama açığı olan CVE-2026-48618 de var. Temmuz sürümü (v22.23.2, v24.18.1, v26.5.1) on bir düzeltme daha getirdi ve bunların üçü yüksek önem dereceli.

Temmuzdaki yüksek önem dereceli hatalardan ikisi HTTP/2 katmanında: CVE-2026-56846, bekletilen başlık bloklarının maxSessionMemory sınırını aşmasına ve uzaktaki bir istemcinin sunucu belleğini tüketmesine izin veriyor; CVE-2026-56848 ise nghttp2’de bir heap use-after-free hatası. Üçüncüsü CVE-2026-58043, Permission Model’de verilen bir dosya sistemi izninin izin listesi dışındaki yollara uzanmasına yol açıyor. 22, 24 ve 26 sürüm hatları için yüksek önem dereceli düzeltmeler içeren bir sürüm daha 21 Ekim 2026’da geldi.

Sürüm hattı neden tek bir yamadan daha büyük bir risk?

Bir yama ancak sürüm hattınız onu hâlâ alıyorsa işe yarar. PHP 8.1’in güvenlik desteği 2025 sonunda bitti, Node.js 20 de 30 Nisan 2026’da ömrünü tamamladı; ikisinden birini hâlâ çalıştıran sunucular yukarıdaki düzeltmelerin hiçbirini almadı. PHP 8.2 de 31 Aralık 2026’da aynı noktaya geliyor, bu yüzden bugün planlanan bir yükseltme için kötü bir hedef.

İki proje destek sonuna farklı yollardan ulaşıyor ve bu da planlamayı değiştiriyor. Aşağıdaki tablo kısa özetidir.

Kendi hatlarınızı burada kontrol edin:

cPanel’de bir sitenin gerçekte hangi PHP’yi çalıştırdığını nasıl bulursunuz?

Kabuğa güvenmeyin. Bir cPanel sunucusunda php -v varsayılan komut satırı derlemesini bildirir; oysa her alan adı MultiPHP Manager’da seçilen farklı bir daldan, kendi .htaccess dosyasındaki bir işleyici satırından ya da ikisini de geçersiz kılabilen CloudLinux PHP Selector’dan sunulabilir. Kendi sunucularımızdan birinde web sunucusuna 7.2’den 8.5’e kadar dokuz PHP dalı kayıtlı ve varsayılan, sitelerin çoğunun kullandığı sürüm değil.

Gerçek cevabı üç kontrol verir. whmapi1 php_get_vhost_versions, WHM’in her alan adı için kullanıldığını düşündüğü sürümü ve işleyiciyi listeler. CloudLinux üzerindeki hesaplar için selectorctl --user-current --user=<account>, Selector’ın bunu geçersiz kılıp kılmadığını gösterir. Son kanıt ise sitenin içine konan ve PHP_VERSION ile php_sapi_name() değerlerini yazdıran, okunduktan hemen sonra silinen geçici bir betiktir. Bu blogu bir CGI işleyicisinden PHP-FPM’e taşıdığımızda, geçişin işe yaradığını gösteren tek kontrol bu üçüncüsüydü.

Node.js bir hosting sunucusunda nerede saklanır?

Node.js kolayca gözden kaçar, çünkü nadiren tek bir sistem servisi olarak çalışır. cPanel’in Application Manager için kendi paketlerinden, bir dağıtım paketinden, bir kullanıcının ev dizinindeki bir sürüm yöneticisinden, bir uygulamanın içindeki satıcı paketinden ya da bir konteyner imajından gelebilir. Bu yüzden bir sunucu aynı anda üç Node.js sürümü çalıştırabilir ve sistem paketini güncellemek bunlardan yalnızca birini düzeltir.

Pratik envanter, ps -eo pid,user,args | grep -i node ile tüm süreçleri listelemek ve ardından her ikili dosyaya sürümünü sormaktır. PM2 ya da systemd tarafından yönetilen her şey yeniden başlatılana kadar eski çalışma ortamını korur; yeniden başlatma yapılmayan bir güncelleme açıklı kodu bellekte bırakır.

Konteynerler bir katman daha ekler. Bir konteynerin içindeki Node.js servisi, ana makinede ne kurulu olursa olsun imajının derlendiği çalışma ortamını kullanır; bu yüzden düzeltme ancak imaj yamalı bir tabandan yeniden derlenip konteyner yeniden oluşturulduğunda gelir. Aynısı CI çalıştırıcıları için de geçerlidir ve bunlar sunucu envanterinde neredeyse hiç görünmedikleri için kolayca unutulur. Derleme hattınız eski bir imajda çalışıyorsa, ürettiği her çıktı o eski çalışma ortamını da beraberinde taşır.

Uygulamalı bir örnek: bir siteyi PHP 8.1’den 8.4’e taşımak

Bu blog da başlangıçta hesap varsayılanı olduğu için bir CGI işleyicisi üzerinden sunulan PHP 8.1 ile çalışıyordu. Taşıma işlemi, sürüm değişikliğinin aynı zamanda bir işleyici değişikliği olduğunu iyi hatırlattı. Alan adını whmapi1 php_set_vhost_versions ile PHP-FPM altında PHP 8.4’e geçirdik; bu komut sitenin .htaccess dosyasındaki işleyici satırını da yeniden yazdı.

Sürümün yanında iki şey daha değişti. CGI işleyicisi altında PHP web sunucusunun kendi kullanıcısıyla çalışıyordu, bu yüzden yapılandırma dosyasının o kullanıcı tarafından okunabilir olması gerekiyordu; FPM altında ise hesap sahibi olarak çalışıyor, bu da wp-config.php dosyasını yeniden 600 moduna sıkılaştırmamıza ve WordPress’in kendi yüklemelerini ve güncellemelerini yazabilmesine olanak verdi. Geçişten sonraki ilk kontrol, yani php_sapi_name() değerini ve süreç kullanıcısını yazdıran geçici bir betik, yeni işleyicinin gerçekten kullanıldığının tek kanıtıydı. Taşıdığınız her sitede ikisini de hesaba katın ve geçişi diğerlerine geçmeden önce tek bir sitede deneyin.

Sunucularınızda ne yapmalısınız?

1. Yalnızca varsayılanı değil, her çalışma ortamını listeleyin. Kurulu her PHP derlemesi için php -v çalıştırın ve her sitenin ya da FPM havuzunun gerçekte hangi sürümü kullandığını kontrol edin. Node.js için her servisi, konteyner imajını ve CI çalıştırıcısını node --version ile kontrol edin.
2. Önce ömrü dolmuş hatlardan çıkın. PHP 8.1 ve öncesini 8.4 ya da 8.5’e, Node.js 20’yi 24 LTS’e yükseltin. Bu adım tek bir yamadan daha fazla riski kapatır.
3. Desteklenen hatları güncel sürüme yamalayın. En az eylül PHP derlemeleri ve Node.js 22.23.2, 24.18.1 ya da 26.5.1, ardından ekim sürümleri.
4. Eski ikili dosyayı yüklemiş olanı yeniden başlatın. PHP-FPM havuzları, uzun süre çalışan PHP işçileri ve her Node.js süreci, yeniden başlatılana kadar açıklı kodu bellekte tutar.
5. FPM soketlerini gözden geçirin. Unix soketlerini tercih edin; bir havuz TCP üzerinden dinliyorsa onu loopback adresine bağlayın ve yalnızca listen.allowed_clients ayarına güvenmeyin.
6. Kullanmadığınızı kapatın. Hiçbir site SOAP ya da Phar kullanmıyorsa bu eklentileri derlemeden ya da havuzdan çıkarın.
7. HTTP/2’nin önüne bir sınır koyun. İstek boyutu ve bağlantı sınırları olan bir ters vekil sunucu, bellek tüketme girişimlerini Node.js sürecine ulaşmadan karşılar.
8. Duyurulara abone olun. php.net sürüm akışı ve nodejs-sec e-posta listesi, planlanan sürümlerden size önceden haber verir.

İki çalışma ortamının altındaki çekirdek de aynı disiplini ister; paylaşımlı sunucularda koruduğumuz ayarlar paylaşımlı bir Linux sunucu için beş çekirdek ayarı yazısında.

SSS: 2026’da PHP ve Node.js güvenlik sürümleri

PHP 8.1’i 2026’da bir üretim sunucusunda çalıştırmak hâlâ güvenli mi?

Hayır. PHP 8.1, PHP projesinden 2025 sonunda güvenlik düzeltmesi almayı bıraktı, bu yüzden 2026 düzeltmelerinin hiçbiri upstream tarafında onun için yayımlanmadı. Bazı satıcılar seçilmiş düzeltmeleri geriye taşıyor ve bu işe yarıyor, ancak desteklenen yol 8.4 ya da 8.5.

Node.js 20’nin ömrü ne zaman doldu ve bu 2026’da ne anlama geliyor?

Node.js 20’nin ömrü 30 Nisan 2026’da doldu. O tarihten beri güvenlik sürümü almıyor, dolayısıyla 2026’da daha sonra yayımlanan her Node.js düzeltmesi onda eksik. 24 LTS’e ya da daha fazla zamana ihtiyacınız varsa 22’ye yükseltin, çünkü 22 Nisan 2027’ye kadar destekleniyor.

PHP 8.2 mi PHP 8.4 mü: bugün hangisi daha iyi bir yükseltme hedefi?

PHP 8.4. 8.2 dalının ömrü 31 Aralık 2026’da doluyor ve geriye yalnızca birkaç haftalık güvenlik düzeltmesi kalıyor; 8.4 ise 2028 sonuna kadar destekleniyor. Birkaç ay içinde iki kez yükseltme yapmak, doğrudan 8.4’e geçmekten daha fazla test maliyeti getirir.

Node.js 22 mi Node.js 24 mü: bir sunucu hangi LTS hattını kullanmalı?

Yeni kurulumlar için Node.js 24. İkisi de desteklenen LTS hatları, ancak 24 Nisan 2028’e kadar, 22 ise yalnızca Nisan 2027’ye kadar destekleniyor. Bir bağımlılığın henüz hazır olmadığı yerlerde 22’yi koruyun ve yerine geçecek sürümü şimdiden planlayın.

cPanel’de php -v neden web sitemin kullandığından farklı bir sürüm gösteriyor?

Çünkü komut satırı ve web sunucusu ayrı ayrı yapılandırılır. Bir alan adı MultiPHP Manager, bir .htaccess işleyicisi ya da CloudLinux PHP Selector aracılığıyla başka bir daldan sunulabilir. PHP_VERSION ve php_sapi_name() değerlerini yazdıran geçici bir betik, sitenin gerçekte ne çalıştırdığını gösterir.

PHP paketlerini güncellersem düzeltmenin geçerli olması için bir şeyi yeniden başlatmam gerekir mi?

Evet. PHP-FPM havuzları ve uzun süre çalışan PHP işçileri yeniden başlatılana kadar eski kodu bellekte tutar; mod_php kullanan Apache ise zarif bir yeniden yükleme yerine tam bir yeniden başlatma ister. Paketi yeniden başlatma yapmadan güncellemek, açıklı kodu çalışır halde bırakır.

CVE-2026-91768 sonrasında IPv6 TCP soketinde dinleyen bir PHP-FPM havuzu risk taşır mı?

Eylül derlemelerine kadar taşıyordu. İzin verilen istemciler kontrolü bir IPv6 adresinin yalnızca bir kısmını karşılaştırıyordu, bu yüzden liste atlatılabiliyordu. Güncelleyin ve havuzun ağdan hiç erişilemez olması için bir Unix soketini ya da yalnızca loopback üzerinde dinleyen bir TCP dinleyicisini tercih edin.

Paylaşımlı hosting sunucuları 2026’da SOAP ve Phar eklentilerini kapatmalı mı?

Hiçbir sitenin kullanmadığı yerlerde, evet. İkisi de 2026 düzeltmelerinin konusu oldu ve yüklenmemiş bir eklentiye saldırılamaz. Önce kontrol edin, çünkü bazı faturalama sistemleri ve entegrasyonlar hâlâ SOAP’a dayanıyor.

Bir Node.js HTTP/2 servisi bellek tüketme saldırılarına karşı nasıl korunur?

Önce yamalı bir sürüme güncelleyin, çünkü CVE-2026-56846 oturum bellek sınırını atlatıyordu. Ardından önüne istek boyutu, başlık ve bağlantı sınırları olan bir ters vekil sunucu koyun; böylece kötüye kullanan istemciler Node.js sürecine ulaşmadan kesilir.

Bir sunucu ekibi PHP ve Node.js güvenlik sürümlerinden nasıl önceden haberdar olur?

php.net sürüm duyurularını takip edin ve nodejs-sec e-posta listesine abone olun. Node.js her güvenlik sürümünden günler önce bir ön duyuru yayımlar; bu da bakım pencerelerini ve yeniden başlatmaları planlamak için zaman bırakır.

Kaynaklar

• PHP 8 ChangeLog, php.net
• Desteklenen sürümler, php.net
• Haziran 2026 güvenlik sürümleri, nodejs.org
• Temmuz 2026 güvenlik sürümleri, nodejs.org
• Node.js sürüm takvimi, GitHub