Arista VeloCloud Orchestrator: sömürülen CVE-2026-114625'i düzelten kesin build'ler

Aktif olarak sömürülen bir açık için train bazlı yama

Arista'nın VeloCloud Orchestrator'ındaki CVE-2026-114625 olarak takip edilen ve 9.9 önem derecesi verilen kritik bir SQL injection açığı, sahadaki saldırılarda aktif olarak sömürülüyor. Arista ayrıntıları 22 Ekim'de SA-0199 numaralı güvenlik bülteninde açıkladı ve düzeltmeyi haritalandıran bir dev.to yazısı operasyonel pürüzü vurguluyor: orchestrator ayrı release train'ler halinde tutuluyor ve her train kendi yamasını aldı. 5.2 üzerindeki bir dağıtım, 6.4 üzerindekinden farklı bir build gerektiriyor; başka bir train'in düzeltmesini kurmak hiçbir işe yaramıyor.

Hangi build'ler açığı kapatıyor

Bültenin dev.to özetine göre:

• 5.2: 5.2.3.18 öncesinde etkileniyor; 5.2.3.18 ve sonrasında düzeltildi
• 6.1: 6.1.3.10 öncesinde etkileniyor; 6.1.3.10 ve sonrasında düzeltildi
• 6.4: 6.4.2.12 öncesinde etkileniyor; 6.4.2.12 ve sonrasında düzeltildi

Bu listenin dışında üç tespit noktası var. Hosted ve Dedicated orchestrator'ları Arista kendisi yamaladı, dolayısıyla bu müşteriler hiçbir şey kurmuyor; ancak yazı, hiçbir veriye dokunulmadığını varsaymak yerine sağlayıcıdan tenant'ın maruziyet penceresini teyit etmeyi öneriyor. VeloCloud Gateway ve VeloCloud Edge savunmasız kodu hiç içermiyor, bu da yama kapsamını orchestrator host'larına daraltıyor. 7.0 train'i listede yok ve Arista'nın adı geçmeyen sürümleri savunmasız saymadığı bildiriliyor.

Eylül'deki düzeltme bu düzeltme değil

Her train, daha önceki iki açık için zaten build'ler almıştı: Eylül'de CVE-2026-93952 ve Temmuz'da CVE-2026-16812. O build'ler yeni açığa karşı hâlâ savunmasız. 5.2 train'inde 5.2.3.16 Eylül açığını kapatmıştı ama 5.2.3.18'in altında kalıyor; 6.4'te 6.4.2.8 aynı işi yaptı ama 6.4.2.12'nin altında. Eylül yamasını işin sonu sayan ekiplerin yeniden kontrol etmesi gerekiyor.

6.1 train'i daha da karışık. dev.to makalesine göre Arista, Eylül açığının 22 Ekim itibarıyla yalnızca 5.2 ve 6.4 train'lerinde düzeltildiğini belirtiyor; 6.1'de 6.1.3.7'ye kadar olan sürümleri etkiliyor ve listelenmiş bir düzeltme sürümü yok. İki bülten de 6.1.3.10'un Eylül sorununu kapatıp kapatmadığını söylemiyor ve makalenin tavsiyesi, cevabı çıkarsamak yerine Arista'dan yazılı teyit almak.

Desteklenmeyen train'ler

Arista, destek ömrü sona ermiş sürümleri değerlendirmemiş durumda ve bülten, bu train'lerdeki müşterileri yükseltme seçeneklerini görüşmek için Technical Assistance Center'a yönlendiriyor. Yazı bunu rutin bir bakım penceresinden daha yavaş bir yol olarak çerçeveliyor ve erken başlamaya değer diyor; bu noktayı, daha önceki iki orchestrator açığının yaklaşık üç ay içinde sömürüldüğü şeklinde bildirilmesi de pekiştiriyor.

Yama penceresi hemen kapatılamazsa

Arista'nın geçici önlemleri önceki bültenlerini yineliyor: VCO web arayüzü erişimini güvenilen yönetim ağlarıyla sınırlayın, bilinen kötücü adreslerden gelen bağlantıları izleyin, orchestrator host'undan beklenmeyen giden trafiği gözlemleyin, normal işlemlerde gerekmeyen giden portları engelleyin, backdoor daemon'ları ve webshell'ler arayın ve son yönetici etkinliğini açıklanamayan değişiklikler için inceleyin. Bu adımlar erişilebilirliği azaltır ama injection'ı ortadan kaldırmaz ve makalenin belirttiği gibi, arayüzün varsayılan erişilebilirliğini engelleyen bir VCO ayarı yok.

Yükseltmek, kurtarmakla aynı şey değil

Bültenin yükseltmenin saldırganın zaten kazandığı erişimi kaldırıp kaldırmadığını söylemediği bildiriliyor; dolayısıyla yamasızken erişilebilir olan bir orchestrator'un yükseltmeden sonra temiz sayılmaması gerekiyor. Yazının aktardığına göre Arista'nın kanıt rehberi, düzeltme bunların üzerine yazmadan önce VCO web erişim loglarını, backend uygulama loglarını, sistem loglarını, veritabanı loglarını ve ilgili dosya sistemi zaman damgalarını saklamak. Makale ayrıca bir iş sırası öneriyor: standby ve lab örnekleri dahil tüm orchestrator host'larının envanterini çıkarın, her build'i kendi train'iyle karşılaştırın, internete erişilebilir orchestrator'ları önce yamalayın, partner tarafından yönetilen tenant'ların aynı build gereksinimini karşıladığını teyit edin ve dağıtım bittikten sonra build'leri yeniden kontrol edin; çünkü çok tenant'lı yapılarda kısmi dağıtımlar sık yaşanıyor.

Neden önemli

Orchestrator, bir SD-WAN yapısının yönetim düzlemidir; oradaki bir ele geçirme, yönettiği her edge'e ulaşabilir. Bu, yaklaşık üç ay içinde bildirilen üçüncü sömürülen VCO açığı ve bu da "yakın zamanda yamaladık" ifadesini güvenilmez bir güvenlik iddiası yapıyor. Train bazlı yama modeli somut bir tuzak yaratıyor: Eylül CVE'sini düzelten build'ler şimdi hâlâ savunmasız, dolayısıyla güvenlik train varsayımlarına değil build düzeyinde envantere bağlı. Ve yamanın bir saldırganı kanıtlanabilir şekilde çıkarmadığı için log ve zaman damgası toplama, yükseltmenin kendisiyle aynı bakım penceresine ait.