30 сентября 2026 года в 4 часа дня по времени Эр-Рияда Cisco опубликовала бюллетень безопасности об уязвимости CVE-2026-76504 в Cisco Catalyst SD-WAN Manager, системе, с помощью которой компании с несколькими филиалами управляют всей сетью филиалов с одного экрана. Оценка критичности составляет 9.8 из 10, для эксплуатации не нужны ни учетная запись, ни пароль, Cisco сообщает, что узнала об активной эксплуатации в сентябре, и обходного решения нет. В тот же день Национальное управление кибербезопасности Саудовской Аравии (NCA) выпустило предупреждение 2026-7889 с уровнем «Критический», призвав организации изучить бюллетень и установить обновление.

Главный вопрос не технический: кто ставит патч?

Две недели назад мы писали об эксплуатируемой уязвимости в другом устройстве Cisco, том, что управляет идентификацией и доступом, и разобрали там основы управления уязвимостями. На этот раз самый важный вопрос не технический. Возможно, вы вообще не управляете своей сетью филиалов: ее может вести для вас оператор связи или ИТ-компания по договору управляемых услуг. Если так, то кто обновит систему сегодня ночью, кто проверит, не проник ли кто-то до обновления, и что говорит ваш договор, если не произойдет ни того, ни другого?

Что на самом деле опубликовала Cisco

Новости всего несколько часов, поэтому эти факты взяты непосредственно из бюллетеня Cisco и предупреждения NCA, а не из публикаций в прессе:

  • Продукт: Cisco Catalyst SD-WAN Manager, ранее известный как vManage. В бюллетене указано, что он уязвим независимо от конфигурации.
  • Причина: некорректная обработка URI-кодирования в HTTP-запросах позволяет специально сформированному запросу обойти правило аутентификации, предназначенное для защиты определенной конечной точки API, и злоумышленник получает доступ к API с привилегиями пользователя admin.
  • Предварительные условия: никаких. Удаленный злоумышленник без аутентификации и базовая оценка CVSS 9.8.
  • Статус: активно эксплуатируется. Cisco PSIRT сообщает, что узнала об эксплуатации в сентябре 2026 года и что уязвимость была обнаружена при разборе обращения в службу поддержки Cisco Technical Assistance Center.
  • Обходное решение: отсутствует. Исправление состоит в обновлении до исправленной версии.
  • Местное предупреждение: предупреждение NCA 2026-7889 от 30 сентября 2026 года. В нем перечислены 14 целевых секторов, фактически все, от торговли и инвестиций, финансов и экономики и здравоохранения до образования, транспорта и промышленности.

Исправленные версии согласно бюллетеню:

Текущая ветка версийПервая исправленная версия
Старше 20.9Перейти на исправленную версию
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

Обратите внимание на первую строку. Тех, кто работает на версии старше 20.9, ждет не небольшое обновление, а переход на другую ветку версий. Это требует планирования, и откладывать это нельзя.

Почему именно эта система

Сеть SD-WAN связывает филиалы, склады и головной офис через любые доступные каналы, и всё это управляется из одной центральной системы. Именно там прописываются политики: какой трафик идет по какому каналу, какой филиал к какой системе имеет доступ и какие настройки отправляются на маршрутизатор каждой площадки. Одно изменение в центре доходит до каждого филиала. В этом и весь смысл.

Та же особенность и есть опасность. Тот, кто добрался до API этой системы с правами администратора, имеет дело не с одним устройством, а с консолью, которая управляет конфигурацией всей сети. Касса в филиале, канал связи со складом и доступ к бухгалтерской системе за пределами головного офиса могут проходить через сеть, которой управляет эта система. Ей место в самом верху списка критически важных активов, как бы далеко она ни казалась от повседневного управления.

Облако Cisco или ваш дата-центр? От этого зависит, кто действует

Бюллетень различает два способа эксплуатации системы, и разница очень практическая:

  • В облаке Cisco: в бюллетене сказано, что уязвимость затрагивает SD-WAN Manager независимо от конфигурации, и описаны два облачных случая. В средах Cisco Catalyst SD-WAN Cloud Hosted Cisco уже применила меру по ограничению доступа, но мера смягчения не является исправлением, поэтому обновление до исправленной версии из таблицы выше по-прежнему необходимо, и стоит спросить, кто его выполнит. В Cisco SD-WAN Cloud (Cisco Managed) версия 20.15.605 устраняет уязвимость, Cisco сообщает, что никаких действий пользователя не требуется, а версию можно проверить через функцию Help в интерфейсе сервиса. Только в этом последнем случае обновление лежит на стороне вендора. Ваша задача по-прежнему состоит в том, чтобы получить письменное подтверждение и попросить проверить журналы за предшествующий период.
  • Локально, на вашей площадке или в дата-центре вашего провайдера: здесь никто не обновит систему за вас, если этого не требует договор. До обновления мера, описанная Cisco, состоит в том, чтобы ограничить доступ к системе из незащищенных сетей, например из интернета, и защитить управляющие компоненты SD-WAN фильтрующим устройством, например межсетевым экраном.

Так что первый вопрос не в том, используете ли вы Cisco. Вопрос в том, где работает ваша система управления сетью и кто отвечает за ее обновление. Если ответ знает только провайдер, это первый пробел, который нужно закрыть, и он не технический.

Обновление не скажет, проник ли кто-то раньше

Cisco узнала об эксплуатации в сентябре и опубликовала исправление в последний день месяца. Иными словами, уязвимость эксплуатировалась еще до того, как появилось какое-либо обновление. Обновление сегодня ночью закрывает дверь. Оно не говорит, прошел ли кто-то через нее раньше и не оставил ли после себя учетную запись или изменение конфигурации.

Поэтому Cisco опубликовала индикаторы, которые ваша ИТ-команда или провайдер должны искать в двух конкретных журналах системы, serviceproxy-access.log и vmanage-server.log:

  • Запросы к j_security_check с неизвестных или неавторизованных IP-адресов.
  • Любой символ в пути запроса, закодированный в URI, например %6a_security_check, где %6a обозначает закодированную букву j. Именно так эксплойт обходит правило аутентификации. Cisco подчеркивает, что %6a лишь пример: может использоваться кодирование любого отдельного символа в запросе, поэтому команде нужно искать все закодированные варианты j_security_check, а не только %6a.
  • Отдельно в vmanage-server.log: запросы к j_security_check с неизвестных адресов для имен пользователей, начинающихся с viptela-reserved-. Это встроенные служебные учетные записи системы, поэтому само появление имени в журнале не является признаком компрометации. Значение имеет неизвестный источник.

Cisco также предупреждает, что эти индикаторы иногда могут появляться при нормальной работе, поэтому их нужно сравнивать с обычной активностью сети, прежде чем делать выводы.

Тот же урок проявился на этой неделе с двумя критическими уязвимостями Citrix NetScaler, которые Агентство по кибербезопасности и защите инфраструктуры США (CISA) 27 сентября добавило в свой каталог известных эксплуатируемых уязвимостей (Known Exploited Vulnerabilities). CISA заявило, что злоумышленники активно эксплуатируют их по всему миру, призвало организации по возможности проверить признаки компрометации до установки патча и указало, что любая организация, подозревающая компрометацию, должна сохранить криминалистические доказательства до установки обновлений, потому что обновления могут стереть следы произошедшего. Правило действует и здесь: проверьте, сохраните копию журналов, затем обновляйтесь, не позволяя проверке стать поводом откладывать обновление на дни.

Если ваша сеть работает как управляемая услуга: что сказано в договоре?

Основные меры кибербезопасности (Essential Cybersecurity Controls) NCA, редакция 2024 года, обязательны для государственных органов и их аффилированных компаний, а также для организаций частного сектора, которые владеют критической национальной инфраструктурой, эксплуатируют или размещают ее. NCA настоятельно рекомендует всем остальным организациям Королевства их применять. Даже если ваша компания ими не связана, это самый понятный местный ориентир того, что должно быть в договоре с любым провайдером, который обслуживает часть ваших технологий:

  • В договорах с третьими сторонами, сбой у которых может затронуть ваши данные или услуги, включая соглашения об уровне обслуживания: неразглашение и безопасное удаление ваших данных по окончании услуги, порядок взаимодействия при инциденте кибербезопасности и обязанность третьей стороны выполнять ваши требования и политики кибербезопасности (мера 4-1-2).
  • Отдельно в договорах с поставщиками ИТ-аутсорсинга и управляемых услуг: оценка рисков кибербезопасности с подтвержденными мерами снижения до подписания, а центры управляемых услуг кибербезопасности для мониторинга и эксплуатации, использующие удаленный доступ, должны полностью находиться на территории Королевства (мера 4-1-3).
  • В управлении уязвимостями: классифицировать уязвимости по критичности и устранять их в соответствии с этой классификацией, подписаться на надежные источники новостей о новых уязвимостях и проверять обновления в непроизводственной среде перед их установкой (мера 2-10-3).

Обратите внимание на то, чего меры по управлению уязвимостями не говорят: они не устанавливают никакого срока для установки критического обновления. Эту цифру нужно прописать в вашем собственном договоре. Иначе провайдер ставит патч, когда может, а не когда это нужно вам.

Сообщение, которое стоит отправить провайдеру сегодня

Чтобы задать эти вопросы, не нужно быть техническим специалистом, и не нужно ждать встречи. Попросите ответы в письменном виде:

  • Работает ли наша сеть на Cisco Catalyst SD-WAN Manager? И где он работает: в облаке Cisco, у нас или в вашем дата-центре?
  • Какая на нем версия, и когда он будет обновлен до исправленной версии, с указанием даты и часа?
  • Доступен ли интерфейс управления из интернета прямо сейчас? Если да, ограничили ли вы доступ до обновления?
  • Проверили ли вы два журнала, названные Cisco, на опубликованные индикаторы и сохранили ли копию до обновления? Что вы нашли?
  • Кто первым сообщил нам об этом предупреждении: вы или новость, которую мы прочитали? И какой порядок уведомления согласован на следующий раз?

Последний вопрос самый важный. Если вы узнали о предупреждении из статьи, а не от своего провайдера, проблема больше, чем одна эта уязвимость.

Взгляд Origami

Мы создаем бизнес-системы. Мы не продаем и не обслуживаем сетевое оборудование. Но каждая система, которую мы создаем для клиента с несколькими филиалами, работает поверх сети, которую проектировали не мы: касса филиала отправляет данные на сервер, склад обновляет остатки, электронный счет-фактура уходит на платформу. А обычный ответ на вопрос, кто ставит патчи на сеть, звучит так: провайдер обо всем позаботится. Это успокаивающий ответ, и это не ответ.

Для саудовского владельца бизнеса мы видим в этой уязвимости напоминание о том, что аутсорсинг переносит работу, но не ответственность. Управляемая услуга правильный выбор для многих компаний при условии, что в договоре есть три измеримые вещи: установленный срок для установки критических обновлений, письменное уведомление о каждом предупреждении, которое касается ваших систем, и отчет после каждого инцидента о том, что было проверено и что найдено. Эти пункты ничего не стоят хорошему провайдеру, и они выявляют слабого провайдера раньше, чем это сделает уязвимость.

Итог

  • Если вы эксплуатируете Cisco Catalyst SD-WAN Manager у себя или у своего провайдера, обновление до исправленной версии срочная, а не плановая работа, а версии старше 20.9 требуют перехода на исправленную ветку.
  • До обновления: закройте доступ к системе из интернета и разместите управляющие компоненты за межсетевым экраном, как описано в бюллетене.
  • Проверьте оба журнала и сохраните копию до обновления, потому что эксплуатация началась до публикации исправления.
  • Если сеть работает как управляемая услуга, отправьте вопросы выше сегодня, а при следующем продлении добавьте в договор срок для критических обновлений и порядок уведомления.

Источники