Node.js Temmuz 2026 Güvenlik Sürümleri: Permission Model Bir Emniyet Kemeri

29 Temmuz Çarşamba günü Node.js projesi aktif üç sürüm hattının hepsi için güvenlik sürümleri yayımladı: v26.5.1, v24.18.1 ve v22.23.2. Sürüm yayına çıkmadan önce iki kez ertelendi: bir kez ek test ve doğrulama için, bir kez de altyapı sorunları yüzünden. Toplamda 11 CVE kapatılıyor: üçü High, beşi Medium, üçü Low. Resmi duyuruda benim için en önemli iki konu var: her backend'in dayandığı HTTP ve TLS altyapısı, bir de on bir düzeltmenin üçünün, Permission Model'in kodun hiç izin verilmemiş dosyalara erişmesine yol açmasıyla ilgili olması.

Sürümde neler var#

High seviyedeki düzeltmeler:

• CVE-2026-56846: bellekte tutulan HTTP/2 header blokları maxSessionMemory sınırını atlatabiliyor ve uzaktan bellek tükenmesine yol açabiliyor. 24.x ve 22.x'i etkiliyor.
• CVE-2026-56848: nghttp2_session_mem_recv() çalışırken nghttp2_session_mem_send() yeniden girişli (re-entrant) olarak çağrılabiliyor ve bu durum heap üzerinde use-after-free ile sonuçlanıyor. Üç hattın hepsini etkiliyor.
• CVE-2026-58043: Permission Model'in yol eşleştirmesi, radix-tree önek sınırlarında dosya sistemi erişimini gereğinden fazla verebiliyor. Yani tek bir yola erişim izni verilen bir saldırgan, amaçlanan izin listesinin dışında okuma ya da yazma yapabiliyor.

Medium seviyedekiler şunlar: iki HTTPS Agent yeniden kullanım hatası (CVE-2026-56850'de mTLS istemci kimlikleri farklı istemci sertifikalarına sahip istekler arasında yeniden kullanılıyor; CVE-2026-58040'ta ise TLS oturumunun yeniden kullanımı, farklı kimlik politikaları arasında hostname doğrulamasını atlıyor, bu da CVE-2026-48934 için yapılmış eksik bir düzeltme), sıfırlanıp yeniden bağlanmış önbellekteki bir statement'ı tekrar çalıştırabilen node:sqlite tag store iterator'ı (CVE-2026-58041, 26.x ve 24.x), 256'dan fazla A kaydı içeren yanıtlarda process'i sonlandıran dns.resolveAny() (CVE-2026-58042) ve sahte bir TypedArray uzunluğuyla çöken senkron node:zlib API'leri (CVE-2026-58045).

Low seviyedekiler: --allow-fs-write ile izin verilen yolların dışına yazan trace events (CVE-2026-56847) ve process.report (CVE-2026-58039), bir de request smuggling'e kapı açabilen header kırpma sorunu (CVE-2026-58044): maxHeadersCount / maxHeaderPairs sınırını aşan header'lar, Content-Length dahil, req.headers içinden gizlenebiliyor, ama Node bunları framing için kullanmaya devam ediyor. Sürüm ayrıca undici ve llhttp'yi de güncelliyor.

Aynı çitte üç delik#

Duyuru CVE-2026-58043 için bir proof of concept yayımlamıyor, bu yüzden tam olarak hangi yol biçimlerinin etkilendiği konusunda tahmin yürütmeyeceğim. Üç Permission Model düzeltmesinin ortak noktası, tek tek herhangi birinden daha ilginç: bir izin listesi, ona danışan her kod yolu kadar güçlüdür. Burada bir yanda önek sınırında uç bir durumu olan bir yol eşleştirici vardı, öbür yanda --allow-fs-write'a uymadan dosya yazabilen iki tanılama özelliği: tracing ve process report'lar. Tanılama özellikleri, biri onları yanlış dizine yönlendirene kadar kimsenin yazma API'si olarak düşünmediği türden özelliklerdir.

Sandbox değil, emniyet kemeri#

Node.js permissions dokümantasyonu bu konuda ferahlatıcı derecede açık sözlü. Modeli, güvenilir kodun kendisine izin verilmemiş kaynaklara istemeden dokunmasını engelleyen bir emniyet kemeri olarak tanımlıyor ve kötü niyetli kod söz konusu olduğunda "does not provide security guarantees" diyor. Aynı sayfa Node.js güvenlik politikasına da atıf yapıyor; bu politikaya göre runtime, çalıştırması istenen her koda güvenir.

Her gün paralel olarak birkaç coding agent çalıştırıyorum. Bir agent üretilmiş script'leri ya da testleri çalıştırdığında, cazip kısayol workspace'e yazma izniyle node --permission kullanıp buna sandbox demek. Ama değil. Kod düşmanca olabilecekse, ister enjekte edilmiş bir talimatı uygulayan bir model olsun, ister ele geçirilmiş bir bağımlılık ya da kullanıcının sağladığı bir plugin, sınırın process'in dışında olması gerekir:

• hiçbir credential ya da SSH anahtarı mount edilmemiş bir container veya VM
• tek bir yazılabilir workspace'e sahip, salt okunur bir root dosya sistemi
• root olmayan bir kullanıcı ve kısıtlanmış dış ağ erişimi (egress)
• tüm bunların içinde, hataları yakalayan katman olarak --permission

Bu sürüm, bu katmanlı yaklaşımın haklılığını gösteriyor. Çitin artık sağlam olduğunu kanıtlamıyor.

HTTP/2 ve mTLS servisleri için pazartesi kontrol listesi#

• Manifest'i değil, runtime'ı doğrulayın. engines alanı gerçekte neyin çalıştığı hakkında hiçbir şey söylemez. Build edilmiş image'ın içinde ve CI runner'larında kontrol edin; sabitlenmemiş base image tag'leri ancak yeniden build ederseniz işe yarar.

node -p "process.versions.node"   # expect 26.5.1, 24.18.1, 22.23.2 or later on that line

• HTTP/2'nin nerede sonlandığını bilin. Self-hosted Next.js uygulamalarım bir VPS üzerinde nginx'in arkasında duruyor, bu yüzden ilk sorum Node'un kendisinin dış dünyayla HTTP/2 konuşup konuşmadığı. Public bir port üzerinde http2.createSecureServer() çağıran bir servis, iki HTTP/2 High açığı için öncelikli.
• Paylaşılan HTTPS Agent'ları denetleyin. Tek bir https.Agent farklı istemci sertifikalarına ya da farklı hostname doğrulama politikalarına sahip isteklere hizmet ediyorsa, CVE-2026-56850 ve CVE-2026-58040 sizi ilgilendiriyor. Yamadan sonra bile her istemci kimliğine kendi Agent'ını verirdim.
• Node ile yazdığınız proxy'leri kontrol edin. Giden header'ları req.headers üzerinden yeniden oluşturup body'yi yeniden kullanılan bir upstream bağlantısına pipe etmek, tam olarak CVE-2026-58044'ün şekli.
• 24.x veya 26.x üzerinde node:sqlite kullanıyorsanız createTagStore araması yapın.
• 26.x, 24.x ve 22.x dışındaki her şeyi açık kabul edin. Sürüm alan hatlar yalnızca bunlar ve duyuru, End-of-Life sürümlerin her zaman etkilendiğini belirtiyor.

Benim görüşüm#

Yama rutin: sürümü yükselt, yeniden build et, yeniden deploy et. Asıl değerli olan ders. Tek bir sürümde üç Permission Model düzeltmesi olması, özelliğin kötü olduğu anlamına gelmiyor; insanların onu stres testine soktuğunu gösteriyor ve bu sağlıklı bir şey. Ama agent'ların çalıştırdığı ya da üçüncü taraf kod için tehdit modeliniz --permission ile başlayıp bitiyorsa, bu hafta o kodu gerçekte neyin sınırladığını yazıya dökün ve bir sonraki duyuru kararı sizin yerinize vermeden önce etrafına gerçek bir container ya da VM sınırı koyun.