Hızlı cevap: Ömrü biten (End of Life, EOL) çalışma zamanı, üreticinin artık güvenlik yaması yayımlamadığı sürüm demektir. 21 Ekim 2026 günü Node.js ve PHP, desteklenen hatlarına kritik yamalar verdi, ancak Node.js 18 ve 20 ile PHP 8.0 ve 8.1 gibi EOL hatlar bu yamaları ALMADI. Yani bu sürümleri kullanan sistemler aynı açıklara (Brotli bellek taşması, TLS doğrulama atlatma, PHP core uzaktan kod çalıştırma) karşı savunmasız kaldı ve kalıcı olarak öyle kalacak. Tek doğru aksiyon yama değil göçtür: desteklenen bir sürüme geçmek. Bugün yapmanız gereken önce envanter çıkarmak, sonra desteklenen sürüme planlı geçiş yapmaktır.

Güvenlik dünyasında en sinsi risk, henüz keşfedilmemiş açık değildir. Çünkü keşfedilmemiş açık için bir savunma planı yapamazsınız zaten. Asıl sinsi risk, herkesin bildiği ama kimsenin önceliklendirmediği risktir: üreticinin desteğini çektiği bir çalışma zamanının üzerinde üretim trafiği taşımak. 21 Ekim 2026 bunun somut bir örneğini verdi. Aynı gün hem Node.js hem PHP, yüksek önem dereceli açıklar için eşzamanlı yama yayımladı. Desteklenen sürümler korundu. Ömrünü tamamlamış sürümler ise listede bile yer almadı, çünkü onlara yama çıkmıyor. Bu makale tekil bir CVE'nin derinliğine değil, bu olayı bir kanıt olarak kullanarak çalışma zamanı yaşam döngüsünü nasıl yöneteceğinize odaklanıyor.

EOL (ömrü biten) çalışma zamanı ne demek

Her büyük çalışma zamanının bir yaşam döngüsü vardır. Node.js için bu döngü aktif LTS (uzun süreli destek), bakım (maintenance) LTS ve ardından EOL şeklinde ilerler. PHP için her minör dal iki yıl aktif hata düzeltmesi, bir yıl yalnızca güvenlik düzeltmesi alır, sonra desteği biter. EOL noktasına gelen bir sürüme üretici artık hiçbir güvenlik yaması yayımlamaz. Kod aynı kalır, ama dünya değişir: o koddaki bir açık keşfedildiğinde, resmi bir düzeltme asla gelmez.

Buradaki kritik yanılgı şudur: çalışan bir sistem, güvenli bir sistem değildir. Node.js 18 ya da PHP 8.1 bugün sorunsuz çalışıyor olabilir. Performans iyi, hatalar yok, iş akışı aksamıyor. Ama güvenlik açısından bu sistem, yeni bulunan her açık için savunmasız bir hedef haline gelmiştir. 21 Ekim olayı tam da bunu gösterdi.

21 Ekim 2026 olayı neden kanıt

O gün iki paralel sürüm çıktı ve ikisi de EOL hatların neden tehlikeli olduğunu kanıtladı.

Node.js tarafında on düzeltme yayımlandı, bunların dördü yüksek önem dereceliydi. En ciddisi, Brotli kod çözücüdeki sınır dışı yazma açığıydı (CVE-2026-111497), ki hazırlanmış bir Brotli girdisi ile uzaktan kod çalıştırmaya yol açabiliyor. Yanında TLS sertifika hostname doğrulamasının atlatılmasına izin veren iki açık daha vardı (CVE-2026-106069 ve CVE-2026-105483). Yamalar v22.23.4, v24.22.1 ve v26.12.1 sürümlerine çıktı. Node 18 ve 20 bu listede yok. Detaylar için Node.js Ekim 2026 güvenlik güncellemesi rehberimize bakabilirsiniz.

PHP tarafında daha da sert bir tablo vardı: PHP core içinde iki ayrı uzaktan kod çalıştırma açığı (CVE-2026-109618 ve CVE-2026-109619), CVSS v4.0 skoru 9.2 ile Kritik. Gayriresmi takma adıyla PHP2Shell. Yama sürümleri 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 olarak yayımlandı (kesin sürümleri php.net duyurusundan teyit edin). PHP 8.0 ve 8.1 ömrünü tamamladığı için resmi yama almadı. Bu açığın teknik derinliği için PHP kritik RCE PHP2Shell analizimizi inceleyebilirsiniz. TLS doğrulama atlatma açıklarının ayrıntısı ise TLS hostname doğrulama atlatma yazımızda duruyor.

Mesaj net: desteklenen sürümde iseniz güncelleyin ve korunun. EOL sürümde iseniz güncelleyecek bir şey yok, göç etmekten başka seçenek yok.

Zorunlu tablo: çalışma zamanı yaşam döngüsü ve aksiyon

Aşağıdaki tablo, 21 Ekim 2026 itibarıyla yaygın sürümlerin durumunu ve her biri için doğru aksiyonu özetler. Sürüm eşleşmesi "etkilenebilir" demektir, kesin açık değil, çünkü dağıtımınızda backport veya azaltma olabilir. Yine de EOL hatlarda durum tartışmasızdır: resmi bir düzeltme hiç gelmeyecek.

Çalışma zamanı Sürüm EOL durumu Doğru aksiyon
Node.js 18.x EOL (destek bitti) Göç şart, 22 veya 24 LTS'e geçin
Node.js 20.x EOL (2026 ortası) Göç şart, 22 veya 24 LTS'e geçin
Node.js 22.x (LTS Jod) Destekleniyor v22.23.4'e güncelleyin
Node.js 24.x (LTS Krypton) Destekleniyor v24.22.1'e güncelleyin
Node.js 26.x (Current) Destekleniyor v26.12.1'e güncelleyin
PHP 8.0 EOL (destek bitti) Göç şart, 8.3 veya 8.4'e geçin
PHP 8.1 EOL (destek bitti) Göç şart, 8.3 veya 8.4'e geçin
PHP 8.2 Destekleniyor (güvenlik) 8.2.35'e güncelleyin
PHP 8.3 Destekleniyor 8.3.36'ya güncelleyin
PHP 8.4 Destekleniyor 8.4.27'ye güncelleyin
PHP 8.5 Destekleniyor 8.5.12'ye güncelleyin

Tablodaki satırların yarısı "göç şart" diyor. Bu tesadüf değil. Pek çok kurumsal sistem, hâlâ EOL bir çalışma zamanının üzerinde duruyor ve bunun farkında bile değil.

Çalışma zamanı yaşam döngüsünü nasıl yönetmeli

Bu bir kerelik bir tamir değil, süreklilik gerektiren bir süreçtir. Sağlam bir program dört adımda kurulur.

Birinci adım envanterdir. Hangi sunucu, hangi konteyner, hangi fonksiyon hangi çalışma zamanı sürümünü koşuyor sorusunun cevabını yazılı tutmalısınız. Node için sunuculardan node sürümü çekilir, PHP için ise her web sunucusunun CLI ve FPM sürümü ayrı ayrı sorulur, çünkü bunlar farklı olabilir. Göremediğiniz şeyi yönetemezsiniz, bu yüzden envanter her şeyin temelidir.

İkinci adım, bu envanteri makine okunur bir yazılım malzeme listesine (SBOM) dönüştürmektir. SBOM, hangi bileşenin hangi sürümde çalıştığını standart bir biçimde tutar ve yeni bir CVE çıktığında "biz etkilendik mi" sorusunu dakikalar içinde yanıtlamanızı sağlar. SBOM'u zafiyet önceliklendirme ve tedarikçi kanıtıyla birleştirmenin yolunu SBOM ve VEX ile zafiyet önceliklendirme yazımızda anlatıyoruz. Çalışma zamanı, tedarik zincirinizin en alt katmanıdır, dolayısıyla tedarik zinciri saldırılarına karşı savunma stratejiniz EOL çalışma zamanlarını da kapsamalıdır.

Üçüncü adım, düzenli bir yama yönetimi sürecidir. Desteklenen sürümlerde yama hızlı ve düşük riskli olmalı, EOL yaklaşan sürümler ise önceden takvime alınmalıdır. Bir sürümün EOL tarihini, o tarih geldiğinde değil, en az iki çeyrek önce planlamaya koymak doğru olandır. Yama yönetiminin uçtan uca kurgusunu yama yönetimi rehberimizde bulabilirsiniz.

Dördüncü adım, risk önceliklendirmesidir. İnternete açık, kimlik doğrulaması olmadan erişilebilen ve kritik veri işleyen sistemler önce gelir. PHP2Shell gibi herhangi bir multipart form POST isteğiyle tetiklenebilen bir açık, internete bakan EOL bir PHP sunucusunu listenin en tepesine taşır.

Göç planı: önce test, sonra üretim

Göç, panikle yapılan bir üretim değişikliği değil, kontrollü bir mühendislik işidir.

İlk olarak test ortamında hedef sürümü ayağa kaldırın. Node 18'den 22'ye veya PHP 8.1'den 8.3'e geçerken kırılma noktaları genelde kaldırılmış API'ler, değişen varsayılan davranışlar ve bağımlılık uyumsuzluklarıdır. Otomatik testleriniz burada hayat kurtarır. Konteyner kullanıyorsanız temel imajı (base image) yenileyin, çünkü imajdaki çalışma zamanı değişmeden konteyner içi hiçbir şey değişmez. Bir takım güncellemesi (apt veya benzeri) çalıştırmak çoğu zaman üretim imajını değiştirmez, bu sık yapılan bir hatadır.

Sonra aşamalı dağıtım yapın: önce bir örnek, ardından kademeli olarak tümü. Geri dönüş (rollback) planınız hazır olsun. Çalışma zamanı göçü, altyapı sertleştirmesiyle birlikte düşünülmelidir, bu yüzden Linux sunucu sertleştirme rehberimizi göç sonrası kontrol listesine ekleyin. Göç tamamlandığında envanteri ve SBOM'u güncellemeyi unutmayın, aksi halde bir sonraki CVE çıktığında yine karanlıkta kalırsınız.

KAOS ve DSET yaklaşımı

DSET'in yerel yapay zekâ motoru KAOS, bir sistemi değerlendirirken önce çalışma zamanı sürümlerini tespit etmeye çalışır: HTTP başlıkları, hata sayfaları, davranışsal parmak izleri ve açık uç noktalardan edinilen ipuçlarıyla. Tespit edilen sürüm, bilinen CVE veritabanlarıyla ve varsa KEV (bilinen sömürülen açıklar) listeleriyle eşleştirilir, ardından internete açıklık ve veri hassasiyeti gibi faktörlere göre önceliklendirilir.

Burada dürüst olmak önemli: sürüm tespiti bir hipotezdir, kesin teyit değildir. Bir sunucunun "Node 20" sinyali vermesi, backport yamalı bir dağıtım kullanıyor olabileceği ihtimalini ortadan kaldırmaz. Bu yüzden KAOS, over-claim frenine sahiptir: sürüm eşleşmesini "etkilenebilir" olarak raporlar, "kesin açık" demez. Kesin teyit, kontrollü ve yetkili bir aktif doğrulama gerektirir. EOL durumu ise bu belirsizliğin dışındadır çünkü olgusaldır: Node 18 ya da PHP 8.1 için resmi yama yoktur ve olmayacaktır, bu bir tahmin değil takvimdir.

Sık sorulan sorular

EOL bir sürüm hâlâ çalışıyorsa neden göç etmem gerekiyor? Çünkü "çalışmak" ile "güvende olmak" aynı şey değildir. EOL bir çalışma zamanında bulunan her yeni açık kalıcı olarak açık kalır, üretici düzeltme yayımlamaz. 21 Ekim 2026'daki Node ve PHP açıkları tam olarak bunu gösterdi: desteklenen sürümler yama aldı, EOL sürümler aynı açıklara savunmasız bırakıldı. Sisteminiz bugün sorunsuz çalışıyor olabilir, ama bu onun bir sonraki açıkta hedef olmayacağı anlamına gelmez.

EOL sürümü göç edemeyeceğim kadar kritik bir sistemde kullanıyorum, ne yapmalıyım? Kısa vadede riski azaltabilirsiniz ama ortadan kaldıramazsınız. Sistemi internetten izole edin veya WAF arkasına alın, saldırı yüzeyini daraltın, erişimi sıkı kimlik doğrulamasına bağlayın ve şüpheli istek kalıplarını izleyin. Örneğin PHP2Shell için session.upload_progress devre dışı bırakmak bir şüpheli yolu kapatır ama açığı tümüyle gidermez. Bunlar zaman kazandıran önlemlerdir, kalıcı çözüm değildir. Desteklenen sürüme göç, her durumda planlanmak zorundadır.

EOL takvimini nereden takip etmeliyim? Node.js için resmi sürüm takvimini nodejs.org üzerinden ve endoflife.date gibi derleyici kaynaklardan izleyebilirsiniz. PHP için php.net üzerindeki desteklenen sürümler sayfası her dalın aktif destek ve güvenlik destek bitiş tarihlerini verir. Bu tarihleri kendi envanterinizle eşleştirip bir sürümün EOL olmasına en az iki çeyrek kala göç planını devreye almak, acil durum yaması yerine kontrollü geçiş yapmanızı sağlar.

Kaynaklar

Çalışma zamanı envanterinizi çıkarmak, EOL risklerini önceliklendirmek ve kontrollü bir göç planı kurmak için DSET ile iletişime geçin. Ekibimiz Ankara Hacettepe Teknokent merkezinden kurumsal altyapınızın yaşam döngüsü yönetimine uçtan uca destek verir.