Sadece PHP Değil: Node.js, Java ve Linux Altyapılarında Gözden Kaçan Kritik Zafiyetler ve Kapatma Rehberi

Geçen hafta PHP çekirdeğinde çıkan iki kritik RCE açığını ve sunucu panellerinde nasıl yamanacağını ayrı bir yazıda anlatmıştım. Yazının ardından meslektaşlarımdan ve sunucu yöneten arkadaşlardan benzer sorular geldi. Apache ya da PHP-FPM gibi alışılmış web sunucularında bir açık duyurulunca herkes hemen harekete geçiyor. İş arka planda sessizce çalışan Node.js servislerine ya da Spring üzerindeki Java uygulamalarına gelince ise garip bir rahatlık başlıyor.

"Nasılsa Nginx arkasında çalışıyor, dışarıya açık portu yok" düşüncesi bugün sunucu yönetiminde yapılabilecek en büyük hatalardan biri. Ters vekil (reverse proxy) trafiği yalnızca yönlendirir. Zararlı bir HTTP başlığını ya da açığı olan bir bağımlılığı kendiliğinden temizlemez.

Bu kez PHP'yi bir kenara bırakıp Node.js, Java, Python ve temel Linux kütüphanelerinde karşımıza çıkan güncel açık türlerine ve bunları terminalden en temiz şekilde nasıl kapatacağımıza bakalım.

1. Node.js: Çalışma Zamanı ve Bağımlılık Derdi

Node.js tarafında açıklar iki yerden gelir. Biri Node.js'in kendisi: V8 motoru, libuv, HTTP/1 ayrıştırıcısı llhttp ya da HTTP/2 katmanı. Diğeri de node_modules klasörünü şişiren üçüncü parti paketler.

Son dönemde Node.js güvenlik bültenlerinde en çok öne çıkanlar şunlar:

• HTTP Request Smuggling ve HTTP/2 DoS: Bozuk biçimli başlıklarla ayrıştırıcı yanıltılıyor, birkaç özel istekle olay döngüsü (event loop) kilitlenip servis yanıt veremez hale geliyor.
• İzin Modeli (Permission Model) atlatma: --permission ile konan dosya sistemi kısıtları sembolik bağlantılar ya da özel karakter dizileriyle aşılıyor. Bu özellik Node 22.13 ile kararlı hale geldiği için artık üretimde de kullanılıyor, dolayısıyla bu açıklar yalnızca deneme ortamlarını ilgilendirmiyor.
• Alt paket açıkları (prototype pollution, path traversal): express, ws, axios ya da tar gibi temel paketlerin eski sürümlerinde, sunucuda izinsiz dosya okuma ve yazmaya kadar varan açıklar bulunuyor.

Node.js ve npm paketleri nasıl güncellenir?

Node.js'i işletim sisteminin varsayılan deposundan kurduysanız muhtemelen çok eski bir sürümde kalmışsınızdır. Node 20'nin desteği Nisan 2026'da bitti. Hala 20 kullanıyorsanız yama beklemek yerine 22 ya da 24'e geçmeniz gerekiyor.

NVM (Node Version Manager) kullanıyorsanız en güncel LTS sürümüne geçip küresel paketleri taşımak için:

nvm install --lts --reinstall-packages-from=current
nvm alias default 'lts/*'
node -v

NodeSource deposu (Ubuntu / Debian) kullanıyorsanız çalışma zamanını doğrudan paket yöneticisiyle güncelleyin:

sudo apt update
sudo apt install --only-upgrade nodejs -y

NodeSource deposu kurulumda seçtiğiniz ana sürüme bağlıdır (örneğin node_20.x). Bu komut sizi aynı ana sürümün son yamasına taşır, 20'den 22'ye geçirmez. Ana sürüm değiştirmek için depoyu yeni sürümle yeniden eklemeniz gerekir.

PM2 ile çalışan servisler: Node.js'i güncelledikten sonra PM2 ya da systemd ile çalışan uygulamalar, siz yeniden başlatana kadar bellekteki eski Node sürümüyle çalışmaya devam eder. PM2 sürecini ve uygulamaları yeni sürümle ayağa kaldırmak için:

pm2 update
# Ya da uygulamaları ortam değişkenleriyle birlikte yeniden yüklemek için:
pm2 reload all --update-env

reload yalnızca cluster modunda çalışan uygulamalarda kesintisizdir. Fork modundaki uygulamalar kısa bir süre için yeniden başlar.

Docker ile çalışıyorsanız sunucuda apt upgrade yapmak konteynerin içindeki Node'u güncellemez. Taban imajı yeniden çekip konteyneri baştan oluşturmanız gerekiyor:

docker pull node:22
docker compose up -d --build

Proje içi paket açıklarını kapatmak için proje dizinine girip bağımlılıkları tarayın. npm audit fix yalnızca sürüm aralığınızı bozmayan güncellemeleri uygular:

cd /var/www/proje-dizini
npm audit
npm audit fix

npm audit fix --force ana sürüm atlayabileceği için onu test etmeden canlı projede çalıştırmayın.

2. Java: JVM, Spring ve Deserialization Açıkları

Kurumsal projelerde ve büyük arka uç servislerinde Java hala ilk tercih. Bu dünyada "bir kere kur, yıllarca dokunma" alışkanlığı da bir o kadar yaygın.

Güvenlik ekiplerinin Java tarafında en sık karşılaştığı tehditler:

• Güvensiz ters serileştirme (insecure deserialization): Jackson, Fastjson ya da Java'nın kendi serileştirme mekanizması üzerinden gelen kurcalanmış veri doğrudan uzaktan kod çalıştırmaya (RCE) dönüşebiliyor.
• Spring Framework ve Apache Tomcat açıkları: Özel hazırlanmış ifadelerle yapılan SpEL injection yetkisiz erişime ve kod çalıştırmaya, HTTP/2 akış manipülasyonları ise servisin çökmesine yol açıyor.
• OpenJDK kriptografi ve bellek hataları: Doğrudan JVM katmanında TLS el sıkışma hataları ya da bellek taşmaları.

Sunucuda OpenJDK ve bağımlılıkları güncelleme

Java uygulamalarında makinedeki OpenJDK çalışma zamanını ve projenin içindeki .jar bağımlılıklarını ayrı ayrı ele almak gerekiyor.

İşletim sistemi seviyesinde OpenJDK güncellemesi

Ubuntu / Debian:

sudo apt update
sudo apt install --only-upgrade 'openjdk-*' -y

AlmaLinux / Rocky Linux / RHEL:

sudo dnf clean all
sudo dnf update 'java-*-openjdk*' -y

Güncellemeden sonra Tomcat ya da kendi Spring Boot servisleriniz yeniden başlatılmadan yeni JVM devreye girmez. Ubuntu'da Tomcat servisinin adı kurulu sürüme göre tomcat10 ya da tomcat9 olur:

sudo systemctl restart tomcat10
# Ya da kendi yazdığınız servis:
sudo systemctl restart uygulama-servisi.service

Maven ve Gradle projelerinde açık taraması

Kodunuzda açığı bilinen bir kütüphane olup olmadığını OWASP Dependency-Check ile terminalden görebilirsiniz. İlk çalıştırmada NVD veritabanını indirdiği için uzun sürer, NVD'den ücretsiz bir API anahtarı alırsanız belirgin şekilde hızlanır.

# Maven projeleri için:
mvn org.owasp:dependency-check-maven:check

# Bağımlılıkların daha yeni sürümlerini listelemek için:
mvn versions:display-dependency-updates

Gradle kullanıyorsanız org.owasp.dependencycheck eklentisini build.gradle dosyasına ekledikten sonra aynı taramayı şöyle çalıştırırsınız:

./gradlew dependencyCheckAnalyze

3. Gözden Kaçan Ortak Katman: glibc, libexpat, OpenSSL

Hangi dili kullanırsanız kullanın, uygulamanız bir yerde işletim sisteminin kütüphanelerine dayanır. Ama bu bağ her dilde aynı şekilde kurulmuyor:

• glibc: Node.js, Python ve JVM dahil paylaşılan kütüphanelerle çalışan neredeyse her program glibc'yi kullanır. glibc'de çıkan bir açık hepsini birden etkiler.
• OpenSSL: Python, PHP, Nginx ve curl sistemdeki OpenSSL'i kullanır. Node.js'in resmi derlemeleri ve NodeSource paketleri ise OpenSSL'i kendi içinde taşır, onu sistem paketiyle değil Node'u güncelleyerek yamarsınız. Java kendi TLS katmanını (JSSE) kullanır, Go da öyle. Yani sistem OpenSSL'ini güncellemek bu ikisini korumaz, korumaması da gerekmez.
• libexpat ve libxml2: XML ayrıştıran Python ve PHP uygulamaları bunlara bağlıdır.

Hangi katmanda neyi kontrol etmelisiniz?

Katman	Öne çıkan açıklar	Çözüm
Node.js (22 / 24 LTS)	HTTP/2 DoS, path traversal, npm alt paket açıkları	nodejs paketini güncelleyip npm audit fix çalıştırın
Java (OpenJDK 17 / 21 / 25)	Deserialization RCE, Spring ve Tomcat açıkları, JVM bellek hataları	OpenJDK paketini ve Maven/Gradle bağımlılıklarını güncelleyin
Python (3.11 ve üstü)	urllib3, cryptography, Pillow ve PyPI tedarik zinciri açıkları	pip-audit ile tarayıp sanal ortam paketlerini yükseltin
Linux sistem kütüphaneleri	OpenSSL, glibc, curl ve libexpat açıkları	apt upgrade ya da dnf update sonrası servisleri yeniden başlatın

Python 3.10'un desteği Ekim 2026'da bitiyor. Hala 3.10 ya da daha eskisini kullanıyorsanız sürüm yükseltmesini de planınıza ekleyin.

Python ortamları için hızlı tarama

Sunucunuzda yapay zeka araçları, otomasyon betikleri ya da Python tabanlı web servisleri çalışıyorsa pip-audit çok işinize yarar:

# Sanal ortamı etkinleştirin
source /var/www/python-app/venv/bin/activate

# pip-audit'i kurup taramayı başlatın
pip install pip-audit
pip-audit --fix

Güncellemeden Sonra En Kritik Adım: Eski Kütüphaneyle Çalışan Süreçler

Linux sunucularda en sık yapılan hata, apt upgrade ya da dnf update çalıştırıp terminali kapatmak. Diskteki OpenSSL ya da glibc güncellense bile o anda çalışan Nginx, Node.js, Java ya da veritabanı süreçleri bellekteki eski, açığı olan kütüphaneyi kullanmaya devam eder.

Hangi servislerin hala eski kütüphaneleri tuttuğunu ve yeniden başlatılması gerektiğini şu iki araçla görebilirsiniz.

Ubuntu / Debian (needrestart, Ubuntu 22.04 ve sonrasında kurulu gelir):

sudo apt install needrestart -y
sudo needrestart -b

AlmaLinux / Rocky / RHEL (needs-restarting):

sudo dnf needs-restarting -s
# Çekirdek ya da glibc güncellendiyse yeniden başlatma gerekip gerekmediğini görmek için:
sudo dnf needs-restarting -r

Bu komutlar güncellenen kütüphanelerin eski sürümünü kullanan servisleri tek tek listeler. Listede çıkanları yeniden başlatmadan işi bitmiş saymayın.

Son Söz

Sunucu güvenliği bir kere kurulup unutulan bir şey değil, sürekli bakım isteyen bir iş. Uygulama katmanını ne kadar yalıtırsanız yalıtın, çalışma zamanlarını ve bağımlılık ağaçlarını düzenli yamamadığınız sürece kapıyı aralık bırakmış olursunuz. Dış dünyaya açık API'leriniz ve mikroservisleriniz varsa bu kontrolleri aylık rutininize mutlaka ekleyin.

Sizin altyapınızda en çok başınızı ağrıtan bağımlılık ya da güncelleme süreci hangisi? Yorumlarda buluşalım.