· kaynak dev.to (home feed)
NextScan'daki sabit kodlanmış JWT anahtarı, kimliği doğrulanmamış saldırganların yönetici konsolunu ele geçirmesine imkân veriyor
NextScan 1.1.0 ile 1.2.0 arası sürümleri, ns-admin konsolunu sabit kodlanmış bir JWT imzalama anahtarıyla birlikte geliyor; bu da kimliği doğrulanmamış saldırganların süper yönetici token'ları sahtesini yapmasına kapı açıyor. VulnCheck bu açığı 9.3 puanla değerlendirdi.

Ne oldu
dev.to'da yayımlanan bir yazı, güvenlik tarama projesi NextScan'daki kritik bir açığı ele alan CVE-2026-126797'yi ayrıntılarıyla anlatıyor. NextScan'ın ns-admin bileşeni; kullanıcıları, tarama görevlerini ve saklanan güvenlik açığı sonuçlarını yönetiyor. 1.1.0'dan 1.2.0'a kadar olan sürümler sabit kodlanmış bir JWT imzalama anahtarıyla birlikte geliyor; yani gizli anahtar fiilen herkese açık ve tüm kurulumlarda ortak. Yazıya göre VulnCheck bu soruna CVSS v4.0 skorunda 9.3 puanı verdi; sömürme için herhangi bir yetki veya kullanıcı etkileşimi gerekmiyor.
Saldırı nasıl işliyor
İmzalama anahtarı gizli olmadığı için onu ele geçiren herkes, doğrulamadan geçen bir token üretebiliyor. Yazıda açıklandığı üzere, kimliği doğrulanmamış bir saldırgan HS256 ile imzalanmış bir token oluşturup X-Access-Token başlığı üzerinden sunabilir ve halka açık olarak bilinen süper yönetici rol kimliğini talep edebilir. Süreçte hiçbir parola yer almıyor. Bu tasarımda token imzası denetimi tek kimlik doğrulama sınırı olduğundan, imzası doğrulanan bir token, sunan kişinin hiç oturum açmamış olması karşın, geçerli sayılıyor.
Tarayıcı konsolları neden hedefte
dev.to yazısı, iç ağdaki güvenlik araçlarının internete açık uygulamalara göre genellikle daha az incelemeden geçtiğini, oysa ns-admin'ın tam da bir saldırganın istediği şeyleri topladığını savunuyor: ortamdaki zayıflıkların haritası, ağ istekleri başlatabilme yeteneği ve saklanan tarama geçmişi. Konsolu ele geçiren kişi kullanıcıları değiştirebilir, tarama kapsamını genişletebilir veya daraltabilir ve saklanan sonuçları düzenleyebilir. Bu durum, iç ağa herhangi bir yoldan erişimi olan saldırgan için değerli bir basamak olmasının yanında; bulgular veya tarama zamanlamaları sessizce değiştirildiğinde yanlış bir güvence kaynağına da dönüşebilir.
Etkilenen sürümler ve düzeltme durumu
Etkilenen aralık 1.1.0 ile 1.2.0 arasında. Yayım anında yazıda atıf yapılan upstream kaydı (kayıt 48) düzeltilmiş bir sürüm belirtmiyordu; bu nedenle operatörler 1.2.0'ın güvenli olduğunu varsalmamalı. Yazar, düzeltilmiş bir sürüm için upstream kaydını ve VulnCheck danışma belgesini izlemeyi öneriyor. Docker dağıtımı ve upstream kaynak kodu, anahtarın ve rol işlemenin nerede olduğunu doğrulamaya yardımcı olabilir; ancak anahtarın kendisi kayıtlara veya sohbetlere kopyalanmamalı.
Geçici önlemler
Yazı, operatörler için birkaç geçici önlem sıralıyor:
ns-admin'ı bir reverse proxy ya da kimlik farkındalıklı erişim katmanının arkasındaki kimlik doğrulamasının ardına yerleştirin ve yalnızca yönetici ağlarıyla sınırlandırın. Genel bir NAT kuralı üzerinden açığa çıkarılmamalı.
Konsoldan kaynaklanan tarama sonuçlarına başka servislerin güvenip güvenmediğini gözden geçirin; zira ele geçirilen bulgular yayılabilir.
Ekip kaynak kodunu güvenle yamalayabiliyorsa, sabit imzalama anahtarını her kurulum için benzersiz bir gizli değerle değiştirin, mevcut token'ları geçersiz kılın ve oturum açma ile rol atama akışının tamamını test edin. Yerel bir yama, üreticiden gelen bir düzeltme değildir; bu nedenle belgelendirin ve upstream bir düzeltme yayımladığında yeniden gözden geçirin.
Erişim kayıtlarında, öncesinde oturum açma olmayan başarılı yönetici isteklerini, token üretim anomalilerini ve kullanıcı ya da tarama zamanlamasında yapılan değişiklikleri inceleyin. Konsol güvenilmeyen kullanıcılarca erişilebilir durumdaysa, saklanan güvenlik açığı sonuçları bağımsız bir karşılaştırmayı hak edebilir.
Yamalama veya önlem sonrasında doğrulama için yazı, bir test anahtarıyla imzalanmış bir token kullanmayı denemeyi ve reddedildiğini doğrulamayı, olağan yönetici oturum açmasını ise ayrıca test etmeyi öneriyor. Etkin anahtar kaynağı, anahtarın değeri yazdırılmadan kayıt altına alınmalı.
Neden önemli
Bu güvenlik açığı, yinelenen bir JWT başarısızlık biçimini gözler önüne seriyor: geçerli bir imza yalnızca token'ın anahtarla imzalandığını kanıtlar, taşıyıcısının kimlik doğrulamasından geçtiğini değil. Her kurulum aynı sabit kodlanmış anahtarı paylaştığında ise o kanıt bile çöker. Yazının çerçevelediği daha geniş ders dağıtım kimliğiyle ilgili: bir tarayıcı tüm kurulumlar için tek bir imzalama gizli anahtarıyla gelmemeli ve bir iç araç, yalnızca genel internet dışında bulunduğu için güvenilir sayılmamalı. Bir kuruluşun zayıflıklarını envanterine alan araçlar başlı başına yüksek değerli hedeflerdir ve bearer token üreten her şey için kurulum başına benzersiz gizli anahtarlar temel standart olmalıdır.
- #security
- #vulnerability
- #jwt
- #authentication
- #nextscan