Cisco выпустила рекомендации по пяти критическим уязвимостям NX-OS: на затронутых коммутаторах Nexus они могут привести к выполнению произвольного кода с правами root. Другой возможный исход — сбой процессов и перезагрузка устройства с потерей доступности сети. Речь о Nexus 3000 и Nexus 9000 в автономном режиме NX-OS, причём возможность эксплуатации зависит от включённых функций. Об этом сообщает BleepingComputer — на источник стоит заглянуть перед составлением плана работ.
Для инженера здесь главное не слово «критические», а условия атаки. Затронуты NX-API, Next Generation OAM (NGOAM) и MPLS OAM. Одна и та же модель в инвентарной ведомости может требовать разных действий в зависимости от режима работы и конфигурации. Разберём типичные выводы, которые легко сделать по заголовку новости, но опасно переносить в рабочий план без проверки.
Мифы и факты о затронутых Nexus
Миф: любой Nexus 9000 уязвим одинаково
Факт: рекомендации относятся к Nexus 3000 и Nexus 9000 в автономном режиме NX-OS. Nexus 9000 под управлением ACI и Nexus 7000, по данным Cisco, не затронуты ни одной из этих пяти уязвимостей. Но строка «Nexus 9000» в учётной системе ещё не отвечает на вопрос о риске: надо сверить режим работы и активные функции конкретного устройства.
На практике начните с привязки инвентарной записи к живому коммутатору: модель, режим, версия NX-OS, роль в сети и ответственная команда. Если в стойке есть пара коммутаторов для отказоустойчивости, проверяйте каждый отдельно. Расхождение конфигураций между ними — вполне рабочая ситуация после миграций и аварийных изменений; делать вывод по одному соседу нельзя.
Миф: раз NX-API выключен, можно закрывать заявку
Факт: NX-API действительно отключён по умолчанию, а CVE-2026-76471 связана со специально сформированным HTTP-запросом к нему. Но ещё три уязвимости — CVE-2026-76485, CVE-2026-76486 и CVE-2026-76501 — связаны с обработкой IP-трафика при включённом NGOAM. Отдельная CVE-2026-76465 относится к MPLS OAM. Проверка одной функции не заменяет проверку остальных.
Ищите не только явное включение в текущей конфигурации. Сверьте, зачем функция появилась: используется ли она системой управления, средствами диагностики или сетевым дизайном. После этого фиксируйте решение — отключать её или оставлять до обновления. Простое «у нас API не используют» без проверки работающей конфигурации слишком легко превращается в ложное чувство безопасности.
Миф: включённый NGOAM означает один и тот же сценарий для всех трёх CVE
Факт: для этой группы уязвимостей требуется NGOAM, однако дополнительные условия различаются. Для CVE-2026-76486 нужен также SRv6 либо NV Overlay. В случае NV Overlay Cisco уточняет конфигурацию VXLAN EVPN: VNI должен быть сопоставлен с интерфейсом NVE, а у него должен быть известен хотя бы один соседний VTEP. CVE-2026-76501 эксплуатируется при включённом SRv6; эта функция поддерживается лишь некоторыми моделями Nexus 9000.
При разборе инцидентного бюллетеня это полезнее общей пометки «NGOAM есть». У инженера должен получиться перечень условий для каждого коммутатора: включён ли NGOAM, используются ли SRv6 или NV Overlay, и выполнены ли необходимые условия для VXLAN EVPN. Такой перечень помогает расставить приоритеты без гадания по названию платформы. При этом отсутствие дополнительного условия для одной CVE не отменяет проверки остальных уязвимостей NGOAM.
Миф: MPLS OAM можно не проверять — он и так выключен
Факт: MPLS OAM отключён по умолчанию, но CVE-2026-76465 применима, когда его явно активировали. Cisco описывает специально сформированный MPLS echo-request, отправленный на IP-адрес затронутого устройства. Для Nexus 9000 с ASIC Silicon One есть отдельное исключение: они не поддерживают MPLS OAM и этой уязвимости не подвержены.
Уточняйте аппаратную платформу и реальное состояние функции, а не полагайтесь на заводские настройки. В сети после нескольких проектов настройки по умолчанию давно могли смениться. Если MPLS OAM нужен для диагностики, согласуйте последствия его отключения с сетевой командой: устранить вектор атаки полезно, но потерять рабочий инструмент поиска неисправностей посреди эксплуатации — плохой обмен.
Миф: временная защита позволяет отложить обновление без плана
Факт: Cisco рекомендует переходить на исправленный выпуск NX-OS; подходящую версию предлагает определить через Software Checker. Для оборудования, которое пока нельзя обновить и перезагрузить, предусмотрены временные механизмы защиты Live Protect для всех пяти уязвимостей. Если NX-API, NGOAM или MPLS OAM не нужны, Cisco рекомендует их отключить.
Это разные меры для разных ограничений. Отключение функции убирает связанный с ней вектор атаки, но требует проверки зависимостей. Live Protect помогает пережить период до окна работ, а не отменяет необходимость определить исправленный выпуск. Обновление закрывайте только после проверки состояния коммутатора и сохранения сведений о том, что установлено и какие функции остались активны.
Что сделать до ближайшего окна работ
- Составьте список устройств. Отделите Nexus 3000 и Nexus 9000 в автономном NX-OS от Nexus 7000 и Nexus 9000 в ACI. Для каждого затронутого устройства запишите модель, текущий выпуск NX-OS, роль и контакт владельца сервиса. Это основа для разговора с эксплуатацией и закупками, если обновление потребует дополнительной подготовки.
- Проверьте функции по каждому коммутатору. Зафиксируйте состояние NX-API, NGOAM и MPLS OAM. Для NGOAM отдельно проверьте SRv6 и NV Overlay; для сценария с NV Overlay — условия VXLAN EVPN, NVE и соседнего VTEP. Для MPLS OAM уточните, не относится ли устройство к Nexus 9000 с Silicon One. Не подменяйте проверку предположением о типовой конфигурации.
- Найдите исправленный выпуск. Сверьте установленную версию с рекомендациями Cisco через Software Checker. Перед изменениями проверьте совместимость выбранного выпуска с конкретной моделью и используемыми функциями, подготовьте резервную копию конфигурации и порядок возврата. Перезагрузку планируйте с учётом роли коммутатора, а не только свободного времени администратора.
- Разделите постоянную и временную меры. Неиспользуемые функции — кандидаты на отключение после проверки зависимостей. Если обновление и перезагрузка пока невозможны, уточните применимость Live Protect и назначьте окно для перехода на исправленный выпуск. По завершении работ повторно проверьте версию, настройки и работоспособность сетевых сервисов.
Где обычно ошибаются при согласовании работ
Первая ловушка — смешать возможность выполнения кода и гарантированный захват коммутатора. Cisco описывает возможность выполнения кода с правами root, но также и сценарий, при котором атака приводит к сбою процессов и перезагрузке. Для ЦОД оба исхода серьёзны: даже без закрепления атакующего внезапная потеря сетевого узла может ударить по приложениям. Поэтому в заявке на изменения фиксируйте не только риск компрометации, но и риск простоя.
Вторая — считать отсутствие известных атак доказательством безопасности. Уязвимости обнаружили при внутреннем тестировании; на момент публикации рекомендаций Cisco не знала о публичных сообщениях или вредоносной эксплуатации. Это полезный контекст для приоритизации, но не повод пропускать проверку конфигурации.
Если для работ нужны поддержка или поставка оборудования, в Казахстане разумно заранее согласовать с поставщиком совместимость конкретной модели и программного выпуска, комплект документации, гарантийные условия и сроки поставки. Не закладывайте замену устройства в план только из-за громкого заголовка: сначала выясните, затронуто ли оно и доступен ли исправленный выпуск. И наоборот, если замена действительно нужна, учитывайте её срок вместе с окном миграции и порядком возврата.
У Cisco одновременно вышли и рекомендации по Cisco License, ранее Smart Software Manager. Это отдельный продукт и отдельная задача: затронутые выпуски уязвимы независимо от конфигурации, обходных решений нет, рекомендовано обновление до 10-202609. Старые выпуски под прежним названием исправления не получат — для них Cisco рекомендует переход на поддерживаемый выпуск. Не смешивайте эту заявку с проверкой функций NX-OS: ответственные и план изменений могут различаться.
Сначала конфигурация, затем обновление
По этой новости нельзя оценивать риск Nexus только по номеру серии. Проверьте режим работы и включённые функции, сопоставьте их с условиями конкретной CVE, затем выберите исправленный выпуск и подготовьте окно работ. Если любите такие разборы без паники и с практическими проверками, подписывайтесь на блог.