Arista, VeloCloud Orchestrator'daki aktif olarak istismar edilen CVSS 9.9 SQL injection açığını bildirdi

Arista Security Advisory 0199'e göre, CVE-2026-114625 olarak takip edilen ve CVSS ölçeğinde 10 üzerinden 9.9 puan alan VeloCloud Orchestrator'daki SQL injection açığı sahadaki saldırılarda istismar ediliyor. İstismar için Enterprise Read Only ya da daha yüksek yetkili geçerli bir hesap gerekiyor; bu, kimlerin saldırabileceğini sınırlıyor ama hesap envanteri gevşek olan her açık orchestrator'ı riske atıyor. dev.to'daki bir yazı, advisory'yi sahiplar için bir iş sırasına dönüştürüyor.

Advisory'nin ortaya koyduğu noktalar

dev.to özetinde belirtildiği gibi, yanıtı yönlendiren iki gerçek var. VCO varsayılan olarak açık şekilde geliyor ve ürünün içindeki hiçbir ayar bu görünürlüğü kaldırmıyor. Ayrıca Enterprise Read Only kadar kısıtlı bir hesap bile injection'ı istismar etmek için yeterli olduğundan, hangi hesapların var olduğunu bilmek, hangi hostların var olduğunu bilmek kadar önemli.

Düzeltilmiş sürümler sürüm hattına göre değişiyor: 5.2 hattı için 5.2.3.18, 6.1 için 6.1.3.10 ve 6.4 için 6.4.2.12. Arista düzeltmeyi kendi Hosted ve Dedicated orchestrator'larına zaten uyguladı. Gateway ve Edge bileşenleri etkilenmiyor ve 7.0 hattında hiçbir şey açıklıklı olarak listelenmemiş. Destek süresi dolmuş hatlarda olanlar bu konuyu Arista TAC ile görüşmeli.

Bir detay operatörleri zor durumda bırakacak: Temmuz ve Eylül'deki VCO açıklarını çözen build'ler güncel düzeltilmiş sürümlerin gerisinde kalıyor; yani son aylarda iki kez yamalanmış bir host bile yükseltme adayı olmaya devam ediyor.

Önce neyi düzeltmeli

Çoğu kurum tek bir akşamda yükseltebileceğinden fazla orchestrator çalıştırdığından, dev.to yazısı şu sırayı öneriyor:

1. Yamasız olduğu herhangi bir anda erişilebilir olan her orchestrator'dan — VCO web erişim logları, backend uygulama logları, sistem logları, veritabanı logları ve dosya sistemi zaman damgaları — bir yükseltmenin bunların üzerine yazmadan önce logları toplayın.
2. Her hostta çalışan kesin build'i kaydedin ve kendi sürüm hattıyla eşleştirin; 6.4 bir build, 5.2 satırıyla değerlendirilemez.
3. Önce dışarıdan erişilebilir orchestrator'ları, ardından iç olanları, sonra lab ve standby örneklerini yükseltin.
4. Partner hesaplarının arkasındaki tenant'ları aynı yükleme penceresine dahil edin; çünkü bir partner girişi genellikle birkaç müşteriye yayılıyor ve yamasız tek bir host, çok müşterili bir olaya dönüşebilir.
5. Pencere kapandığında tüm yapıyı yeniden tarayın; eksik dağıtımlar, çok tenant'lı ortamların en sık başarısız olduğu yerdir.

Hesaplar ve ara dönem önlemleri

İstismar için read-only bir hesap yeterli olduğundan, erişim incelemesi yamanın kendisi kadar ağırlık taşıyor. Yazı; web arayüzü erişimi olan her hesabı saymayı — denetçi ve entegrasyon hesapları, partner personeli ve o günden beri bitmiş bir proje için açılmış her şey — net bir gerekçesi olmayanı silmeyi ve kalması gerekenleri, düzeltilmiş build dağıtılana kadar operatör düzeyi haklara olası bir yol olarak görmeyi öneriyor.

Hemen yükseltilemeyen hostlar için Arista, VCO web arayüzü erişimini güvenilir yönetim ağlarıyla sınırlamayı, bilinen kötücü adreslerden gelen bağlantılara dikkat etmeyi, VCO hostunu beklenmeyen giden trafik açısından izlemeyi, normal işlemlerde kullanılmayan giden portları engellemeyi, backdoor daemon'ları ve webshell'leri aramayı ve son yönetici etkinliğini açıklanamayan değişiklikler açısından incelemeyi öneriyor. Advisory'de adı geçen iki adres 74.82.197[.]86 ve 38.54.50[.]151. VCO web erişim loglarında aranmaya değer desenler: yerli yerinde durmayan URL benzeri yol segmentleri, encode edilmiş karakterler, yerel veya iç servislere yönelik referanslar ve olağandışı derecede yüksek istek hızları.

Advisory'nin açık bıraktığı noktalar

Advisory, bir yükseltmenin erişim kazanmış bir saldırganı sistemden çıkarıp çıkarmadığını ya da ele geçirilmiş bir orchestrator'ın yönettiği edge cihazlarını açığa çıkarmaya devam edip etmediğini söylemiyor. Her iki soru önceki VCO advisory'lerinde de yanıtlanmamıştı; bu yüzden operatörler yamanın canlı bir sızıntıyı kapattığını varsaymamalı.

dev.to yazısı yararlı bir çizgi çekiyor: Açıklık, düzeltilmiş build her erişilebilir hostta çalıştığında kapanmış sayılabilir; olay ise yalnızca korunmuş loglar ve yönetici etkinliği incelemesi bir şey ortaya çıkarmadığında kapanır. Bu iki eşik nadiren aynı güne denk gelir.

Triage için VeloCloud sayfa başlığını arayan bir ZoomEye sorgusu 529 varlık döndürüyor. Yazı, bunun doğrulanmış açık orchestrator'ları değil, görünen VeloCloud web yüzeyini saydığını vurguluyor; yani bu bir etki ölçüsü değil, önce nereye bakılacağına dair bir rehber.

Neden önemli

SD-WAN yapısının yönetim katmanında, aktif olarak istismar edildiği doğrulanmış 9.9 şiddetinde bir SQL injection açığı, kurumsal ağlar için en kötü senaryoya yakın. Üç detay pratik riski artırıyor. Bu hatayı istismar etmek için read-only bir hesap yeterli, bu yüzden unutulmuş denetçi, entegrasyon ve partner hesapları saldırı yüzeyinin parçası haline geliyor. Bu yazının VCO açıkları için yamalanmış hostlar hâlâ açıklıklı, yani geçmiş yamalar güvenlik kanıtı değil. Ve advisory bir yükseltmenin mevcut saldırgan erişimini kaldırıp kaldırmadığı konusunda sessiz olduğundan, giderimin iki yarısı var — bir yama dağıtımı ve bir log-ve-hesap incelemesi — ve olayı ancak ikisini de bitirmek kapatıyor.