CVE-2026-20212 у Cisco Nexus 9000: критичний ризик для мереж AI-центрів обробки даних

CVE-2026-20212 у Cisco Nexus 9000 потребує термінової уваги в AI-центрах обробки даних і високопродуктивних середовищах. Не тому, що є публічні докази атак саме на AI-кластери, а тому, що такі комутатори можуть бути на критично важливих шляхах передавання трафіку.

Вразливість дає неавтентифікованому мережевому зловмиснику можливість виконати код із привілеями root або спричинити перезавантаження пристрою — за умови, що він може дістатися двох сервісів у стандартному L3 VRF комутатора. 1720

У чому суть CVE-2026-20212

Cisco розкрила CVE-2026-20212 2 вересня 2026 року. Її оцінка CVSS становить 9,8 з 10. Проблема міститься в інтеграції Silicon One на окремих комутаторах Cisco Nexus 9000 Series.

У стандартному екземплярі Layer 3 Virtual Routing and Forwarding (L3 VRF) доступні TCP-порти 43210 і 43211. Надіславши спеціально сформований ввід на уразливий пристрій, атакувальник може домогтися виконання коду з правами root. Експлуатація також здатна аварійно завершити процес S1HAL, що може призвести до перезавантаження комутатора. 1720

Термін «мережево доступна» в цьому випадку не означає, що комутатор неодмінно має бути відкритий з інтернету. Ризик виникає для будь-якого скомпрометованого хоста або мережевого сегмента, з якого можна звернутися до стандартного VRF. Тому в дата-центрі слід насамперед перевірити доступність із мереж адміністрування, jump-хостів, спільних сервісів і суміжних маршрутизованих сегментів.

Чому це пріоритет для AI-фабрик

Компрометація root на комутаторі фабрики — це не звичайна серверна помилка ПЗ. Щонайменше атакувальник може порушити критичний мережевий шлях, ініціювавши перезавантаження. Контроль над мережевим пристроєм на рівні root також створює ризик несанкціонованої зміни конфігурації, приховування або спотворення телеметрії, закріплення в середовищі та переходу до підключених систем керування.

Це наслідки, які потенційно випливають із характеру вразливості, а не доказ того, що CVE-2026-20212 уже використовували проти AI-інфраструктури.

Для GPU-кластерів та інших середовищ із великими обсягами внутрішнього трафіку зупинка комутації може позначитися на обмінах між вузлами, потоках до сховищ або зв’язності площини керування. Уразливі комутатори варто віднести до найвищого пріоритету під час тріажу вразливостей.

Які Nexus 9000 уразливі — і що з режимом ACI

Це не проблема для всіх пристроїв із назвою Nexus 9000. Наявні повідомлення описують уразливу групу як 10 платформ Nexus 9000 на базі Silicon One, що працюють на уразливому ПЗ. 231

За даними повідомлень про рекомендацію Cisco, комутатори Nexus 9000 Fabric, що працюють у режимі ACI, не зачеплені саме цією проблемою. 48 Документація Cisco також підтверджує, що комутатори в ACI-режимі використовують окреме середовище та гілку релізів. 46

Однак це не привід спрощувати інвентаризацію. Безпечний порядок перевірки такий:

1. Визначити точну модель комутатора, платформу та ASIC.
2. Перевірити, чи використовується відповідна інтеграція Silicon One.
3. Встановити режим роботи й інстальований реліз ПЗ.
4. Зіставити цю комбінацію з рекомендацією Cisco для CVE-2026-20212 та переліком виправлених релізів.

Не варто робити висновок про уразливість лише за назвою сімейства Nexus 9000. Так само не слід вважати мережу безпечною лише тому, що її комутаційна фабрика не має прямого доступу з інтернету.

Що робити: оновити ПЗ і тимчасово закрити два порти

Cisco випустила оновлення ПЗ для уразливих пристроїв Nexus. 228 Надійне виправлення — перевести кожен уразливий комутатор на відповідний виправлений реліз, визначений Cisco для конкретної платформи. Не варто брати номер версії з переказу стороннього джерела: орієнтуйтеся на дані Cisco для вашої моделі та релізу.

Поки всі уразливі пристрої не оновлено, необхідно зменшити площу атаки:

• застосувати інфраструктурні ACL або правила міжмережевого екрана, щоб недовірені джерела не могли звертатися до TCP/43210 і TCP/43211 у стандартному L3 VRF; 1821
• обмежити доступ до площини керування та між-VRF-зв’язність лише явно дозволеними адміністративними системами;
• перевірити, що jump-хости, системи автоматизації та моніторингу мають тільки необхідні їм права доступу;
• провести оновлення як термінову, але контрольовану роботу з урахуванням резервування фабрики та процедур відкату.

Фільтрація трафіку є тимчасовим стримувальним заходом, а не заміною оновленню: дефект у ПЗ при цьому залишається.

Що відомо про виявлення та експлуатацію

За повідомленнями, вразливість Cisco виявила внутрішньо. 2 На момент розкриття компанія заявила, що не знає про зловмисну експлуатацію, а публічні трекери не фіксували доступного proof-of-concept чи підтверджених випадків використання. 221

Це лише стан публічно доступної інформації на той момент, а не гарантія відсутності спроб атак. Критичну неавтентифіковану RCE у мережевій інфраструктурі слід обробляти з огляду на її вплив і фактичну доступність, а не чекати на появу публічного експлойту.

Окремо: вересневий hardening-реліз IOS XR

У вересневих безпекових оновленнях Cisco також був реліз посилення безпеки IOS XR Software. Це окремий напрям роботи від CVE-2026-20212: проблема Nexus стосується інтеграції Silicon One у вибраних Nexus 9000, тоді як IOS XR — операційна система Cisco для маршрутизаторів.

Реліз IOS XR згрупував внутрішньо виявлені проблеми в сім umbrella CVE, серед яких дві мають оцінку CVSS 9,8. За повідомленнями, обхідних рішень для цих проблем IOS XR немає, тому головним способом захисту є оновлення. 235

Командам мережевої безпеки варто вести це як два пов’язані, але різні процеси: перевірити й оновити уразливі Nexus 9000 для CVE-2026-20212, а також окремо оцінити маршрутизатори IOS XR щодо вересневого hardening-релізу.

Як тут пов’язаний Fire Ant — і де зв’язку немає

Публічних доказів, що пов’язана з Китаєм група, яку Sygnia відстежує під назвою Fire Ant, експлуатувала CVE-2026-20212 або використала її як початковий вектор у розслідуванні IOS XR, немає. Зв’язок тут стратегічний, а не підтверджений ланцюжок експлуатації.

Sygnia повідомила, що Fire Ant націлювалася на маршрутизатори Cisco IOS XR, інфраструктуру автентифікації TACACS і Linux-хости керування. За даними Sygnia, зловмисники використовували скомпрометовану довірену інфраструктуру для збирання мережевого трафіку та облікових даних, приховування слідів активності й дослідження підключених середовищ. 1036

Серед описаних індикаторів та інструментів:

• GRE-тунель на IOS XR-маршрутизаторі, для якого не було очікуваного запису в конфігурації або історії комітів; 910
• збирання трафіку та придушення журналювання чи інших слідів на скомпрометованих маршрутизаторах; 10
• TacTap — набір інструментів для збирання облікових даних із потоків автентифікації TACACS; 1036
• BridgeAgent — Linux-імплант, що маскувався під процес, пов’язаний із Zabbix, на хості, підключеному через GRE. 36

Ключовий висновок для захисту AI-центрів обробки даних: комутатори, маршрутизатори, сервіси AAA/TACACS і хости керування є межами безпеки. Їхня компрометація може дати атакувальнику огляд мережі, привілейовані облікові дані, прихованість і шлях до цінних середовищ.

Практичний чекліст реагування

1. Проведіть інвентаризацію. Знайдіть усі Nexus 9000 з інтеграцією Silicon One і звірте їхній режим та реліз із рекомендацією Cisco.
2. Приберіть зайву доступність. Визначте всі маршрути до стандартного L3 VRF і заблокуйте недовірений доступ до TCP/43210 та TCP/43211. 1821
3. Оновіть уразливі комутатори. Найперше — пристрої, що передають критичний виробничий трафік або трафік AI-фабрики. 2
4. Сегментуйте привілейовану інфраструктуру. Відокремте мережі керування й сервіси TACACS/AAA від робочих навантажень і мереж загального призначення.
5. Збирайте незалежну телеметрію. Надсилайте журнали в системи, які мережевий пристрій не може легко змінити, і розслідуйте незрозумілі прогалини в логах або виводі команд.
6. Створіть базовий профіль тунелів і змін control plane. Перегляньте GRE-тунелі, неочікувані інтерфейси, зміни маршрутизації та нетипову активність зі збирання трафіку — особливо на системах IOS XR. 910
7. Захистіть адміністративні облікові дані. Перевірте доступ до TACACS, змініть облікові дані за підозри на компрометацію та розслідуйте аномалії автентифікації.

CVE-2026-20212 — це термінова задача з оновлення та обмеження доступу. Історія Fire Ant нагадує про ширший ризик: довірену мережеву інфраструктуру слід моніторити й сегментувати так само ретельно, як і обчислювальні системи, які вона з’єднує.