Cisco Catalyst SD-WAN Manager'daki CVSS 9.8 puanlı kimlik doğrulama atlatma açığı aktif olarak istismar ediliyor

Cisco, dev.to'daki bir analize göre Catalyst SD-WAN Manager'daki kritik bir güvenlik açığı olan CVE-2026-76504'ü duyurdu; bu açık, kimlik bilgisi olmayan uzak bir saldırganın tek bir özel olarak hazırlanmış HTTP isteği göndererek yönetici düzeyinde API erişimi elde etmesine olanak tanıyor. Açık CVSS 3.1 ile 9.8 olarak puanlanmış durumda, bir geçici çözümü yok ve yazıya göre Cisco'nun 30 Eylül 2026 tarihli danışma belgesi yayınlanmadan önce istismar ediliyordu.

Atlatma nasıl çalışıyor

Kök neden, URL kodlamanın hatalı ele alınması anlamına gelen CWE-177. Dev.to analizinde yeniden yapılandırıldığı şekliyle, kimlik doğrulama katmanı j_security_check oturum açma uç noktasını, istek URI'si üzerinde düz metin eşleşmesi yapan bir filtreyle koruyor. Saldırgan, bu yoldaki tek bir karakteri yüzde-kodlar — örneğin "j" harfinin onaltılık kodlaması olan %6a gönderir — böylece ham istek artık filtrenin kuralıyla eşleşmez ve kimlik doğrulaması gerektirmediği varsayılır. Arka uç ise URI'yı yönlendirmeden önce çözer, isteği gerçek korumalı uç noktaya yönlendirir ve ayrıcalıklı olarak hizmet eder. İki bileşen isteğin ne olduğu konusunda farklı düşünür ve sahte istek ikisi arasındaki boşluktan geçer.

CVSS vektörü azami düzeydedir: ağ üzerinden erişilebilir, düşük saldırı karmaşıklığı, ayrıcalık gerektirmez, kullanıcı etkileşimi yoktur ve gizlilik, bütünlük ile erişilebilirlik üzerinde yüksek etkiye sahiptir.

Duyurulmadan önce istismar edildi

Analize göre Cisco PSIRT, açıkten bir TAC destek talebi yoluyla haberdar oldu; yani hatayı iç araştırma değil, gerçek bir müşteri olayı gün yüzüne çıkardı. CISA, CVE'yi danışma belgesinin yayınlandığı gün olan 30 Eylül'de Bilinen İstismar Edilen Güvenlik Açıkları kataloğuna ekledi ve federal kurumlara 3 Ekim olarak yama son tarihi verdi. Yazının ortaya koyduğu pratik sonuç şu: savunucular danışma belgesine sahip olmadan önce saldırganlar bu tekniği elinde tutuyordu.

Etkilenen sürümler ve düzeltilmiş sürümler

Her yapılandırma etkileniyor; hatayı ortadan kaldıran bir ayar yok. Listelenen düzeltilmiş sürümler şunlar:

• 20.9 dalı: 20.9.10.1
• 20.12 dalı: 20.12.8.2
• 20.15 dalı: 20.15.6.1 (bulutta barındırılan 20.15.605 zaten düzeltilmişti)
• 20.18 dalı: 20.18.4.1
• 26.1 dalı: 26.1.2.1
• 26.2 dalı: 26.2.1

20.9'dan eski sürümler düzeltme almayacak ve desteklenen bir dala geçilmeleri gerekiyor.

Tespit rehberi

Yazıda atıf yapılan danışma belgesi, savunucuları iki log kaynağına yönlendiriyor: serviceproxy-access.log ve vmanage-server.log. Aranacak parmak izi, bilinmeyen veya beklenmeyen IP adreslerinden gelen ve yüzde-kodlu karakterler içeren j_security_check istekleri. Ayrıca, özellikle viptela-reserved-* adlı dahili servis hesaplarının anormal etkinliğine dikkat edin; saldırganlar erişim kazandıktan sonra bu hesapların kimliğine bürünebilir veya bunları kötüye kullanabilir. Bu uç noktalara gelen meşru trafiğin nadir olması nedeniyle, tanıdık olmayan kaynaklardan gelen kodlu istekler varsayılan olarak düşmanca kabul edilmelidir; bu logları saklamayan veya merkezileştirmeyen kurumlar önce bunu düzeltmelidir.

Neden önemli

SD-WAN Manager, geniş alan ağının kontrol düzlemidir ve tek bir örnek 6.000'e kadar cihazı yönetebilir. Yönetici API erişimine sahip bir saldırganın tek tek şube router'larını ele geçirmesine gerek yoktur — Manager'a bunları yeniden yapılandırmasını, cihaz kimlik bilgilerini toplamasını, trafiği yönlendirmek için yönlendirme politikasını değiştirmesini veya yönetim ağından kurumsal ağa geçiş yapmasını emredebilir. İstismar kimlik bilgisi gerektirmediği ve tek bir istekle yapılabildiği için analiz, internete açık her Manager'ın duyurudan sonraki günlerde parmak izinin çıkarılmış olabileceği konusunda uyarıyor. Yazı ayrıca bunun, kimin izinli olduğuna karar veren kodun uzaktan istismar edilebilir biçimlerde sürekli başarısız olduğu kurumsal altyapıdaki bozuk erişim kontrolünün daha geniş bir örüntüne uyduğunu da belirtiyor.

Ağ ekipleri ne yapmalı

• Kendi dalınız için düzeltilmiş sürüme yükseltin; geçici bir çözüm yok.
• Bir Manager Eylül 2026'nın herhangi bir anında internetten erişilebilir ve yamalanmamış durumdaydıysa, ağın temiz olduğunu varsaymak yerine iki log dosyasını kodlu j_security_check istekleri açısından inceleyin.
• Yönetici API erişimi bu bilgileri açığa çıkarabileceği için, Manager yönetici kimlik bilgilerini, API token'larını ve fabric üzerinden yönetilen cihaz kimlik bilgilerini değiştirin.
• Yamalama sonrasında, bir sonraki kontrol düzlemi açığı açık bir hedef bulmasın diye yönetim erişimini VPN veya katı izin listeleriyle kısıtlayın.