Новая уязвимость VeloCloud Orchestrator получила максимальную оценку CVSS 10.0 и уже используется в атаках на on-premises-инсталляции VCO. По данным The Hacker News, проблема затрагивает сервер управления VeloCloud SD-WAN только в конфигурациях, где Edge-устройства аутентифицируются по сертификатам, а не только по pre-shared key. Для русскоязычных команд это неприятный сигнал: если SD-WAN управляется локальным оркестратором, патчить придется не «когда-нибудь после квартального окна», а в ближайшее окно изменений.
Уязвимость получила идентификатор CVE-2026-93952. О проблеме 22 сентября сообщила Arista, которая после покупки VeloCloud отвечает за продуктовую линейку. По описанию вендора, удаленный атакующий без учетной записи может получить доступ к внутренним функциям и повлиять на сам хост VCO. Формулировка сухая, но смысл вполне приземленный: успешная эксплуатация может привести к компрометации оркестратора и данных, которыми он управляет.
VeloCloud Orchestrator — это не очередная вспомогательная веб-панель, которую можно забыть за VPN. Он управляет Edge-устройствами в SD-WAN-инфраструктуре: политиками, связностью, конфигурациями и состоянием сети. Если злоумышленник получает контроль над VCO, риск не ограничивается одной машиной. Arista прямо предупреждает, что компрометированный оркестратор может дать атакующим доступ к управляемым Edge-устройствам. Для распределенных компаний, сетей филиалов, ритейла, производственных площадок и сервис-провайдеров это уже не «ошибка в админке», а возможный вход в сетевую ткань.
Под удар попадают не все развертывания. VeloCloud Edge может аутентифицироваться к оркестратору в трех режимах: Certificate Deactivated, Certificate Acquire и Certificate Required. В первом случае используется pre-shared key, в двух других — сертификат, выданный оркестратором. Arista пишет, что экспонированы системы, где настроена certificate-based authentication между Edge и VCO, но не уточняет, какой именно из сертификатных режимов имеется в виду. Для атаки также нужен сетевой доступ к веб-интерфейсу VCO и публичная часть сертификата аутентификации Edge. Это не делает баг «безопасным», но помогает трезво оценить периметр: интернет-доступный VCO в такой схеме выглядит особенно плохо.
На 22 сентября исправления доступны не для всех веток. В линейке 5.2 уязвимы версии 5.2.3.15 и ниже, исправление вышло в 5.2.3.16 и новее. В линейке 6.4 уязвимы 6.4.2.7 и ниже, исправление — в 6.4.2.8 и новее. Для 6.1, где уязвимы 6.1.3.7 и более ранние версии, исправления на момент публикации еще нет. То же касается 7.0: затронуты 7.0.0.2 и ниже, фикса пока не указано. Hosted и Dedicated-версии VCO, по заявлению Arista, уже пропатчены. То есть основная головная боль остается у тех, кто держит оркестратор у себя.
Ситуацию делает заметно хуже недавний фон. В июле Arista уже сообщала об эксплуатации другой уязвимости VCO — CVE-2026-16812. Та проблема отличалась тем, что не зависела от настроек: VCO был уязвим по умолчанию, и конфигурацией это не закрывалось. Новая уязвимость VeloCloud Orchestrator уже более узкая по условиям эксплуатации, но попадает в тот же класс неприятностей: управляющая плоскость SD-WAN снова оказывается целью, а не просто фоном для сетевой эксплуатации.
Если обновиться сразу нельзя, Arista рекомендует сузить доступ к веб-интерфейсу VCO до доверенных административных сетей. Это базовая мера, но в таких инцидентах именно она часто отделяет неприятный тикет от ночного восстановления инфраструктуры. Также вендор советует мониторить обращения к VCO с известных вредоносных IP-адресов, отслеживать неожиданный исходящий трафик с хоста оркестратора и блокировать ненужные исходящие порты. Отдельно стоит проверять появление backdoor-демонов и web shell, а также просмотреть недавние действия администраторов на предмет неожиданных изменений.
Arista приводит и конкретные индикаторы компрометации. В файловой системе стоит искать /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond и /etc/systemd/system/vc-sysmon.service. Для файла vc-sysmond указан MD5: dc78e206eaeadec59fc5801fe4556bd0. В nginx-логах подозрителен HTTP-заголовок x-vc-opt. Также названы IP-адреса 142.93.149[.]77 и 104.248.126[.]159. Вендор при этом честно предупреждает: одного признака недостаточно, чтобы уверенно сказать, что именно CVE-2026-93952 стала точкой входа. Нужна нормальная проверка логов, а не охота за одной строкой.
Практический вывод для команд безопасности простой и немного скучный, как все хорошие выводы в инфраструктурной безопасности: сначала инвентаризация, потом патч, потом проверка следов. Нужно понять, есть ли в контуре on-premises VCO, какая ветка и версия установлены, используется ли certificate-based authentication, открыт ли веб-интерфейс шире административных сетей. Если есть подозрение на компрометацию, Arista советует сохранить web access logs, backend application logs, системные и database logs, а также временные метки файловой системы до любых «лечебных» действий. После обновления может понадобиться ротация учетных данных, проверка действий администраторов, аудит управляемых Edge-устройств и восстановление оркестратора из доверенного источника.
История с VCO хорошо показывает, куда смещается внимание атакующих: в управляющие системы, которые связывают десятки и сотни удаленных площадок. SD-WAN, оркестраторы, панели управления и сервисные API становятся тем самым местом, где один уязвимый интерфейс дает непропорционально большой эффект. Для бизнеса это значит, что сетевую «админку» больше нельзя считать внутренней сантехникой: ее придется защищать, логировать и обновлять с той же дисциплиной, что публичные приложения.