Hızlı cevap: Node.js 2026-10-21 güvenlik sürümünde iki HIGH ve bir MEDIUM seviyesinde TLS hostname doğrulama atlatma açığı kapatıldı. CVE-2026-105483 tam genişlikli Unicode rakamlarla yazılan bir IP adresini, CVE-2026-106069 gevşek biçimde bir IP adresine çözülen bir host değerini, CVE-2026-106072 ise standart olmayan IPv4 biçimlerini kötüye kullanıyor. Her üçünde de uygulamanız, aslında konuştuğu sunucuya ait olmayan bir sertifikayı geçerli sayabilir. Çözüm yapılandırmada değil, çalışma zamanında, bu yüzden v22.23.4, v24.22.1 veya v26.12.1 sürümüne yükseltmeniz gerekir.

TLS el sıkışmasında kilit simgesi iki ayrı soruya cevap verir. Birincisi, sertifika güvenilir bir otorite tarafından imzalanmış mı. İkincisi, o sertifika gerçekten şu an bağlandığınız host için mi düzenlenmiş. İkinci kontrol hostname doğrulamasıdır ve çoğu kişi bunu düşünmez bile, çünkü kütüphane sessizce yapar. Node.js 2026 Ekim sürümündeki üç açık tam olarak bu ikinci kontrolü hedef alıyor. Sertifika geçerli, zincir temiz, ama host karşılaştırması atlatılabiliyor. Bu makale yalnızca bu üç açığa odaklanıyor, çünkü tek başlarına ayrı bir tehdit sınıfı oluşturuyorlar.

TLS'te hostname doğrulaması nedir ve neden önemli

Bir istemci example.com adresine bağlandığında sunucu bir sertifika sunar. Bu sertifikanın Subject Alternative Name (SAN) alanında hangi host adlarının veya IP adreslerinin geçerli olduğu yazar. İstemcinin görevi, bağlandığı hedefin bu listede olup olmadığını karşılaştırmaktır. Eğer karşılaştırma doğru yapılırsa, saldırgan başka bir alan adı için düzenlenmiş geçerli bir sertifikayı araya sokamaz, çünkü host eşleşmez.

Sorun şu ki host karşılaştırması bir metin ve adres ayrıştırma işidir. Bir değerin IP adresi mi yoksa alan adı mı olduğu, nasıl normalleştirildiği, hangi karakterlerin rakam sayıldığı, bunların hepsi kenar durumları doğurur. Ayrıştırıcı bir değeri bir biçimde yorumlarken doğrulama katmanı başka biçimde yorumlarsa, ikisi arasındaki boşluğa bir saldırgan yerleşebilir. Üç CVE de tam olarak bu tür bir yorum farkından doğuyor. Sertifikanın kendisi sahte değil, hedefin kimliği yanlış eşleştiriliyor. Temel kavramları TLS SSL yapılandırma ve sertleştirme rehberimizde daha geniş ele alıyoruz.

İki HIGH nasıl çalışıyor

CVE-2026-105483, bir IP adresinin tam genişlikli (fullwidth) Unicode rakamlarla yazıldığı durumu kötüye kullanır. Normal bir IP adresi ASCII rakamlardan oluşur. Ancak Unicode, görsel olarak rakama benzeyen ama farklı kod noktalarına sahip tam genişlikli karakterler içerir. Doğrulama mantığı bu karakterleri normalleştirirken, adresi IP olarak gören katman ile SAN kayıtlarını karşılaştıran katman farklı sonuçlar üretebilir. Böylece bir host, aslında eşleşmemesi gereken bir sertifikayla eşleşmiş sayılır. Bu açık 26.x ve 24.x hatlarını etkiliyor.

CVE-2026-106069 ise bir host değerinin gevşek biçimde bir IP adresine çözülmesini hedef alır. İstemcinin bağlandığı host, standart dışı ama tolere edilen bir biçimde bir IP adresi gibi yorumlandığında, hostname doğrulaması bu değeri yanlış kategoride değerlendirir. Sertifikanın IP için mi yoksa alan adı için mi düzenlendiği ayrımı bulanıklaşır ve doğrulama atlatılabilir. Bu açık 26.x, 24.x ve 22.x hatlarının tümünü etkiliyor, yani kapsamı daha geniş. İkisi de HIGH olarak sınıflandırıldı çünkü sonuç aynı, güvendiğiniz kanal aslında güvenli değil.

106072 ve standart olmayan IPv4 sorunu

MEDIUM seviyesindeki CVE-2026-106072, standart olmayan (non canonical) IPv4 hostname biçimlerinin doğru doğrulanmamasıyla ilgilidir. IPv4 adresleri sadece noktalı ondalık biçimde değil, sekizlik, onaltılık veya tek sayı olarak da yazılabilir. Bu biçimler tarihsel olarak birçok ayrıştırıcı tarafından geçerli sayılır. Doğrulama katmanı bu biçimleri standart biçime indirgemezse, DNS tipindeki SAN kayıtları bir IP uç noktasını doğruluyormuş gibi davranabilir ve beklenmedik bir eşleşme oluşur. Önem derecesi daha düşük olsa da aynı aileye aittir ve aynı sürüme yükseltmeyle kapanır.

Ortadaki adam riski ve dürüst sınırlar

Bu açıkların pratik sonucu ortadaki adam (MITM) saldırısıdır. Uygulamanız bir dış servise, örneğin bir ödeme sağlayıcısına veya bir API'ye bağlanırken, araya girebilen bir saldırgan kendi sunucusunu araya koyar ve başka bir host için düzenlenmiş geçerli bir sertifika sunar. Hostname doğrulaması normalde bu numarayı reddeder. Bu açıklarla reddetmeyebilir, böylece saldırgan trafiği okur veya değiştirir, siz hâlâ güvenli bağlandığınızı sanırsınız.

Dürüst olmak gerekir. Bunlar istemci tarafını, yani sizin uygulamanızın kurduğu dış bağlantıları etkiler. Sömürü, saldırganın ağ yolunda bir MITM konumuna sahip olmasını gerektirir, bu her senaryoda kolay değildir ama kurumsal ağ, ortak Wi-Fi, ele geçirilmiş bir ara düğüm veya DNS manipülasyonu gibi durumlarda gerçekçidir. Yayın anında bu açıklar için yaygın aktif sömürü iddiaları sınırlıdır, resmi teyit dardır. Yine de risk teorik değildir, çünkü kusur sizin kodunuzda değil çalışma zamanının doğrulama mantığındadır ve yama tek gerçek çözümdür. Çift taraflı kimlik doğrulamanın bu tabloyu nasıl güçlendirdiğini mTLS ve çift taraflı TLS yazımızda inceleyebilirsiniz.

Üç TLS açığı tek bakışta

Kimlik Önem Tetikleyen koşul Etkilenen hatlar
CVE-2026-105483 HIGH IP adresi tam genişlikli Unicode rakamlarla yazıldığında hostname doğrulama atlatma 26.x, 24.x
CVE-2026-106069 HIGH Host gevşek biçimde bir IP adresine çözüldüğünde hostname doğrulama atlatma 26.x, 24.x, 22.x
CVE-2026-106072 MEDIUM Standart olmayan IPv4 biçimleri doğrulanmaz, DNS SAN kayıtları IP uç noktalarını doğrulayabilir 26.x, 24.x, 22.x

Ne yapmalı

Yapmanız gereken tek kesin adım yükseltmedir. Bu açıklar yapılandırmayla kapanmaz, çünkü sorun sizin ayarlarınızda değil, çalışma zamanının host karşılaştırma mantığındadır. node -v çıktınız 22.23.4, 24.22.1 veya 26.12.1 sürümünden eskiyse, aynı hattın yamalı sürümüne geçin. Konteyner kullanıyorsanız temel imajı yeniden oluşturun, çünkü yalnızca takım güncellemesi üretim ortamını değiştirmez. Eğer Node 18 veya 20 gibi destek dışı bir hattaysanız bu açıklar sizi de etkiler ama yama almazsınız, bu durumda göç zorunludur, konuyu EOL runtime riski yazımızda ayrıntılı anlatıyoruz.

Yükseltmeden sonra dış bağlantı kuran servisleri, özellikle ödeme, kimlik ve üçüncü taraf API çağrılarını gözden geçirin. Tüm Ekim sürümünü bütün olarak ele almak isterseniz Node.js Ekim 2026 güvenlik güncellemesi yama rehberimiz diğer dokuz düzeltmeyi de kapsar. Sunucu tarafı TLS sonlandırmanızı sağlamlaştırmak için ise web sunucu sertleştirme rehberimiz yararlı bir tamamlayıcıdır.

KAOS ve DSET yaklaşımı

DSET'in yerel yapay zekâ motoru KAOS, bu tür açıkları tespit ederken kanıt temelli bir sıra izler. Önce hedefteki çalışma zamanının sürümünü belirler, sonra bu sürümü bilinen CVE kayıtlarıyla eşler, ardından istismar edilebilirlik ve öncelik için KEV listesi ve benzeri kaynaklarla karşılaştırır. Örneğin 22.x hattında çalışan bir servis gördüğünde CVE-2026-106069 için etkilenebilir hipotezi üretir, çünkü o hat kapsamdadır.

Burada dürüst olmak önemlidir. Sürüm eşleşmesi bir hipotezdir, kesin açık teyidi değildir. Bir dağıtım yamayı geriye taşımış (backport) olabilir veya bir azaltma devrede olabilir. KAOS bu yüzden over claim frenine sahiptir, yani kanıt olmadan kesin dil kullanmaz. TLS hostname atlatma gibi açıklarda kesin teyit, kontrollü bir ortamda aktif doğrulama gerektirir, bunu ancak açık yetkiyle ve güvenli biçimde yaparız. Amaç korku değil, önceliklendirilebilir ve doğrulanabilir bir risk tablosudur.

Sık sorulan sorular

Sertifika geçerliyse hostname doğrulama atlatma nasıl mümkün oluyor? Çünkü sertifikanın geçerliliği ile doğru host için düzenlenmiş olması iki ayrı kontroldür. Bu açıklarda zincir doğrulaması sorunsuz çalışır, saldırganın sunduğu sertifika gerçek ve güvenilir bir otorite tarafından imzalanmış olabilir. Atlatılan şey, o sertifikanın gerçekten bağlandığınız hosta ait olup olmadığını kontrol eden ikinci adımdır. Yorum farkları yüzünden yanlış host doğru kabul edilir.

Bu açıklar sunucumu doğrudan hedef alır mı? Hayır, bunlar öncelikle istemci tarafı açıklardır. Riski taşıyan, uygulamanızın dışa doğru kurduğu TLS bağlantılarıdır, örneğin bir API veya ödeme sağlayıcısına yaptığınız çağrılar. Bir saldırganın bu açığı kullanabilmesi için ağ yolunda ortadaki adam konumuna gelmesi gerekir. Yine de sonuç ciddidir, çünkü güvenli sandığınız bir kanal üzerinden veri sızabilir veya değiştirilebilir.

Sadece yapılandırmayı değiştirsem yeterli olur mu? Hayır. Bu açıkların kökü çalışma zamanının host karşılaştırma mantığındadır, sizin TLS ayarlarınızda değil. Cipher listesini sıkılaştırmak veya protokol sürümünü yükseltmek bu belirli atlatmaları kapatmaz. Tek güvenilir çözüm yamalı Node.js sürümüne geçmektir. Yapılandırma sertleştirmesi ayrı ve değerli bir savunmadır, ama bu açıkların yerine geçmez.

Kaynaklar

TLS doğrulama atlatma açıklarını kurumunuzda değerlendirmek, etkilenen bağlantıları haritalamak ve yama önceliklendirmesi yapmak için DSET ile iletişime geçin. Ekibimiz Ankara Hacettepe Teknokent'te yer alır ve kurumsal altyapılar için kanıt temelli güvenlik değerlendirmesi sunar.