· kaynak dev.to (home feed)
Node.js, TLS doğrulama açığı CVE-2026-106072'yı 22.23.4, 24.22.1 ve 26.12.1 sürümlerinde yamaladı
Orta düzey bir Node.js açığı, TLS client'ların 0177.0.0.1 gibi alternatif IPv4 yazımlarıyla eşleşen sertifikaları kabul etmesine izin veriyordu. Düzeltilen sürümler 22.23.4, 24.22.1 ve 26.12.1.

Açık neydi
dev.to'da yayımlanan bir rehber, CVE-2026-106072 kodlu orta düzey güvenlik açığını ele alıyor; açık, Node.js'in client tarafında TLS sunucu sertifikalarını doğrulama biçimini etkiliyor. Sorun 22.x, 24.x ve 26.x sürüm hatlarını etkiliyor. Düzeltmeler Node.js 22.23.4, 24.22.1 ve 26.12.1 sürümlerinde geldi; kaynak bunları projenin 21 Ekim 2026 tarihli güvenlik sürümleriyle ilişkilendiriyor.
Doğrulama boşluğu nasıl çalışıyor
dev.to rehberine göre, savunmasız kod, IPv4 adresine benzeyen dizgileri önce IP literal olarak sınıflandırmadan işliyordu. Normalleştirilmiş dizgi, sertifikadaki subject alternative names içindeki DNS adlarıyla, IP kimliklerinin bulunması gereken IP-adresi SAN'ları yerine eşleştiriliyordu.
Bunun pratik sonucu şu: 127.0.0.1'i DNS adı olarak listeyen — ama bunun için bir IP-adresi SAN'ı taşımayan — bir sertifika, client aynı adresin alternatif bir yazımıyla (0177.0.0.1, 0x7f.0.0.1, 2130706433 veya 127.1 gibi) bağlanırken doğrulamadan geçebiliyordu.
Kaynağa göre istismar koşullu. Saldırganın, eşleşen sayısal DNS adını içeren ve güvenilir bir certificate authority'den alınmış bir sertifika olması gerekiyor; ayrıca client'ın resolver'ı alternatif yazımı kabul etmeli — glibc, bunu yapan bir resolver örneği olarak gösteriliyor. Rehber, bu sınıf buglar için birim testlerinin her iki koşulu da modellemesi gerektiğini ve resolver ya da sertifika fixture'ı istenen senaryoya uymadığında testlerin güvenli tarafta (fail closed) kalması gerektiğini ekliyor.
Kimler yamalamalı
Etkilenen bir Node.js runtime üzerinde çalışan ve giden TLS bağlantıları kuran her şey kapsamda: web servisleri, arka plan worker'ları, komut satırı araçları, CI işleri ve paketlenmiş uygulamalar. Rehber, birden fazla runtime çalıştıran ekipler için ince bir noktaya da dikkat çekiyor: bir child process'in kullandığı Node.js sürümü, ana isteği karşılayan sürümden farklı olabilir; dolayısıyla sürüm kontrolleri dağıtımın bütününe göre değil, her process'e göre yapılmalı.
Kaynağa göre upstream duyurusu, açığın sahada istismar edildiğine dair bir işaret içermiyor; bu yüzden müdahale çalışmaları etkilenen client servislerine göre önceliklendirilebilir.
Etkilenme sayıları gerçekte ne söylüyor
Rehber, 1 Kasım 2026'da kontrol edildiğinde Node.js ürün parmak izleri için bir ZoomEye sorgusunun 5.539.569 eşleşme döndürdüğünü, CVE'nin kendisi için ayrı bir ZoomEye filtresinin ise sıfır sonuç döndürdüğünü aktarıyor. Yazar bu sayıların sınırları konusunda açık: büyük rakam ürün parmak izlerini sayıyor, doğrulanmış savunmasız kurulumları değil; etkilenen bir TLS client'ın erişilebilir olup olmadığı veya riskli biçimde yapılandırılıp yapılandırılmadığı konusunda hiçbir şey söylemiyor. Bu sayı, bir güvenlik açığı hükmü olarak değil, sahiplik ve sürüm kontrolleri için bir envanter aracı olarak değerlendirilmeli.
Çözüm ve test
Önerilen müdahale runtime'ı, uygulamanın hostname politikasını ve sertifika kararlarına dair tutulan kanıtları kapsıyor:
- Düzeltilmiş bir sürüme yükseltin, ardından derlenen artifact'ın gerçekte hangi runtime sürümüyle çalıştığını doğrulayın.
- Sertifika doğrulama testlerini dört durum için ekleyin — canonical IP, canonical olmayan IP, DNS SAN ve IP-adresi SAN — ve sonucu beklenen kimlik türünün yönlendirdiğini teyit edin.
- Dağıtım sürerken ret oranlarını ve yapılandırma hatalarını izleyin.
Yamanın ötesinde rehber, sertifika doğrulamasından önce host değerlerinin canonical hale getirilmesini ve uygulamanın desteklemesi gerekmeyen belirsiz IP literal'larının reddedilmesini öneriyor. Geçici bir dönüştürme kuralı varsa, servisler arasında tutarsız biçimde uygulanmak yerine belgelenmeli ve test edilmeli. Ekipler ayrıca runtime sürümü, sertifika test sonuçları ve tanık oldukları eski istisnaların kayıtlarını da tutmalı.
Neden önemli
TLS client doğrulaması, bir Node.js servisinin bağlantının diğer ucundaki sunucuya güvenmesini sağlayan mekanizmadır. Belirsiz bir hostname yazımı yanlış türde bir SAN ile eşlenebildiğinde, hatayı her şey miras alır: gönderilen kimlik bilgileri, değiş tokuş edilen token'lar, yürütülen komutlar ve o bağlantı üzerinden verilen yetkilendirme kararları. Önem derecesi orta ve istismar alışılmadık bir sertifika ile uyumlu bir resolver gerektiriyor; ama çözüm, net test durumları eşliğinde rutin bir sürüm yükseltmesi. Giden çağrı yapan o kadar çok Node.js dağıtımı varken — worker'lar, CI işleri, CLI'lar ve paketlenmiş uygulamalar dahil — 22.23.4, 24.22.1 veya 26.12.1'e geçmek ve önerilen sertifika testlerini eklemek, küçük bir maliyetle ince bir güven boşluğunu kapatıyor. Takip için kaynak, okuyucuları Node.js güvenlik sürümü duyurularına, üç sürüm notu sayfasına ve bir CERT.LV güvenlik bildirimine yönlendiriyor.
- #node-js
- #security
- #tls
- #vulnerability
- #patching