Cisco NX-OS CVE-2026-76471 i cztery inne RCE 9.8: o podatności decyduje włączona funkcja, nie wersja

7 października Cisco opublikowało trzy advisory dla NX-OS z pięcioma krytycznymi podatnościami, każdą z CVSS 9.8: CVE-2026-76471 w NX-API, CVE-2026-76485, CVE-2026-76486 i CVE-2026-76501 w NGOAM oraz CVE-2026-76465 w MPLS OAM. Wszystkie dają nieuwierzytelnionemu atakującemu wykonanie kodu jako root na przełącznikach Nexus 3000 i 9000. Wszystkie mają też ten sam haczyk: urządzenie jest podatne tylko wtedy, gdy włączona jest konkretna funkcja, a dwie z tych funkcji są domyślnie wyłączone. Skaner, który porównuje wyłącznie numer wersji, oznaczy jako krytyczne dużo więcej przełączników, niż jest ich naprawdę podatnych.

Wektor CVSS jest identyczny we wszystkich pięciu przypadkach: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. NVD potwierdza 9.8 dla każdego CVE osobno (ocena pochodzi z Cisco jako CNA, NVD ma status „Awaiting Analysis”). Ten wektor nie mówi jednak nic o tym, że do ataku potrzebna jest włączona funkcja. CVSS przyjmuje podatną konfigurację za daną. Jeśli funkcja jest wyłączona, urządzenie po prostu nie jest podatne.

Warunki konfiguracyjne z advisory

Wszystkie trzy advisory mówią o Nexus 3000 i Nexus 9000 w trybie standalone NX-OS. Nexus 9000 w trybie ACI jest na każdej z trzech list „confirmed not vulnerable”, podobnie jak Nexus 7000 i MDS 9000. Dalej warunki się różnią:

Dwie rzeczy z tej tabeli łatwo przeoczyć. Po pierwsze, advisory NGOAM nie podaje, czy NGOAM jest domyślnie włączone, czy wyłączone. Pisze tylko „if NGOAM is enabled”. Nie zakładaj więc, że jest wyłączone, tylko to sprawdź. Po drugie, CVE-2026-76471 dotyczy też UCS 6300 Series Fabric Interconnects. Tam atak idzie przez XML API UCS Manager, które jest domyślnie włączone i nie da się go wyłączyć bez utraty funkcji. Wymaga za to ważnych poświadczeń o niskich uprawnieniach, dlatego Cisco obniża dla UCS 6300 swoją ocenę (SIR) do High. Osobnego wyniku CVSS dla UCS 6300 advisory nie podaje.

Jak sprawdzić urządzenie: komendy z advisory

Cisco podaje komendy, które rozstrzygają affectedness. Warto je zebrać hurtowo z całej floty (przez system zarządzania konfiguracją albo skrypt po SSH) i zestawić z inventory, zanim ktoś otworzy ticket na każdy przełącznik z listy skanera:

Przy NV Overlay advisory każe sprawdzić jeszcze trzy rzeczy: show running-config | begin "interface nve", show nve vni i show nve peers. Jeśli wszystkie trzy zwracają dane, urządzenie może być podatne na CVE-2026-76486.

Przy CVE-2026-76486 samo feature nv overlay nie wystarcza. Według advisory musi istnieć VNI VXLAN EVPN zmapowany na interfejs NVE i przynajmniej jeden nauczony peer VTEP (na przykład przez BGP EVPN albo statyczny peer ingress-replication). Jeśli którakolwiek z trzech komend nic nie zwraca, ścieżka NV Overlay dla CVE-2026-76486 odpada (zostaje ścieżka SRv6). Do tego dochodzi tryb pracy: Nexus 9000 w ACI jest wyłączony z zakresu wszystkich trzech advisory, więc najpierw oddziel w inventory urządzenia ACI od standalone.

Fixed releases: tylko przez Software Checker

Żadne z trzech advisory nie wymienia numerów wydań NX-OS z poprawką. Cisco odsyła do Cisco Software Checker, który dla konkretnej wersji i platformy pokazuje pierwszy naprawiony release. Nie znalazłem w źródłach pierwotnych listy wersji, którą mógłbym tu przepisać, więc jej nie podaję. Jedyny konkret dotyczy UCS 6300: wydania 4.2 i starsze trzeba przenieść na wydanie z poprawką, a dla linii 4.3 pierwszym naprawionym jest 4.3(6j).

W praktyce oznacza to, że cel aktualizacji trzeba wyznaczyć osobno dla każdej pary platforma i wersja. Przy okazji warto wrzucić do Software Checkera wszystkie advisory dla danej wersji, nie tylko te pięć. Advisory NGOAM informuje, że należy do większej publikacji z 7 października i do „Cisco NX-OS Software Security Hardening Release: October 2026”. Zapisz w rejestrze, z jakiego dnia pochodzi odczyt Checkera, bo przy wcześniejszych wydaniach Cisco widziałem, jak remediation zmienia się, choć advisory nie.

Co Cisco daje do czasu aktualizacji

Kolejność priorytetów

Pięć CVE z tym samym 9.8 nie znaczy pięciu identycznych priorytetów. Proponuję taką kolejność (to moja ocena, nie zalecenie Cisco):

1. Standalone Nexus z włączonym NX-API, osiągalnym z szerszej sieci. NX-API przyjmuje żądania HTTP i jest zwykle włączane pod automatyzację, więc łatwo o urządzenia, na których nikt już nie pamięta, że działa. Atak wymaga tylko dostępu sieciowego do tej usługi. Advisory nie mówi, na których interfejsach ani portach nasłuchuje NX-API, więc osiągalność trzeba ustalić z własnej konfiguracji.
2. Fabryki VXLAN EVPN i SRv6 z włączonym NGOAM. Tu wystarczą pakiety IP do interfejsu IP urządzenia, czyli potencjalnie z płaszczyzny danych, nie tylko z sieci zarządzania. Jeśli NGOAM nie jest używane operacyjnie, no feature ngoam jest najszybszą zmianą do rozważenia.
3. Włączone MPLS OAM. Ta sama klasa skutku, ale funkcja jest domyślnie wyłączona i rzadziej spotykana na Nexusach. Przy okazji: Nexus 9000 z Silicon One w ogóle nie może jej włączyć.
4. UCS 6300. Wymaga poświadczeń, Cisco ocenia na High. Dla wydań 4.2 i starszych Cisco każe przejść na wydanie z poprawką, co jest też sygnałem do planu migracji.
5. Urządzenia, gdzie żadna funkcja nie jest włączona, i Nexus 9000 w ACI. Zamknij jako „not affected” z dowodem: wynik komend show feature z datą. Aktualizację zaplanuj w normalnym cyklu, bo każda zmiana konfiguracji może warunek przywrócić.

Odwrotną sytuację opisywałem przy CVE-2026-20212 na Nexus 9000 z Silicon One: tam podatna usługa była osiągalna w konfiguracji domyślnej i nie było pytania „czy ktoś to włączył”. Tutaj to pytanie jest kluczowe, a odpowiedź masz w kilku komendach.

Co powinien zrobić VE

(1) Podziel flotę Nexus na standalone i ACI. ACI wychodzi z zakresu wszystkich pięciu CVE. (2) Zbierz z urządzeń standalone wynik komend show feature dla nxapi, ngoam, srv6, nve i mpls_oam, a przy NV Overlay także show nve vni i show nve peers. (3) Nadpisz wynik skanera: finding zostaje tylko tam, gdzie spełniony jest warunek z tabeli, reszta dostaje status „not affected” z dowodem konfiguracyjnym. (4) Dla podatnych urządzeń wyznacz cel aktualizacji w Software Checkerze, a do czasu okna serwisowego rozważ Live Protect albo wyłączenie nieużywanej funkcji. (5) Ustaw ponowną weryfikację po każdej zmianie konfiguracji, bo feature nxapi dodane pod nowy skrypt automatyzacji od razu przywraca podatność. Gdy jedno advisory obejmuje kilka CVE, jak tu przy NGOAM, przyda się też rozróżnienie z wpisu o tym, co właściwie śledzi VM, gdy Cisco grupuje luki: tutaj każde CVE ma inny warunek konfiguracyjny, więc warto śledzić je osobno.

Powiązane na blogu

• Cisco Nexus 9000 CVE-2026-20212 — kiedy default exposure powinno przebić kolejkę CVSS
• Jedno CVE, wiele luk — co śledzi VM, gdy Cisco grupuje podatności
• Cisco IOS XR CVE-2026-20274–20280 — advisory bez zmian, remediation się zmienia

Źródła

• Cisco — Cisco NX-OS Software NX-API Remote Code Execution Vulnerability, cisco-sa-napi-rce-r2shwu2j (7.10.2026, v1.1 z 8.10.2026) — sec.cloudapps.cisco.com
• Cisco — Cisco Nexus 3000 and 9000 Series Switches NGOAM Remote Code Execution Vulnerabilities, cisco-sa-ngoam-rce-LWKQ4BU (7.10.2026) — sec.cloudapps.cisco.com
• Cisco — Cisco Nexus 3000 and 9000 Series Switches MPLS OAM Remote Code Execution Vulnerability, cisco-sa-moam-rce-uBTzYV7 (7.10.2026) — sec.cloudapps.cisco.com
• Cisco Software Checker — sec.cloudapps.cisco.com
• NVD — CVE-2026-76471 — nvd.nist.gov
• NVD — CVE-2026-76485 — nvd.nist.gov
• NVD — CVE-2026-76486 — nvd.nist.gov
• NVD — CVE-2026-76501 — nvd.nist.gov
• NVD — CVE-2026-76465 — nvd.nist.gov
• CISA Known Exploited Vulnerabilities Catalog (stan 2026.10.16: brak tych CVE) — cisa.gov

Nota redakcyjna: stan informacji 18 października 2026. Warunki konfiguracyjne, komendy, listy produktów niepodatnych, mitygacje i status wykorzystania pochodzą z trzech advisory Cisco z 7 października 2026. CVSS 9.8 dla każdego z pięciu CVE potwierdza NVD (ocena Cisco jako CNA, status NVD „Awaiting Analysis”). Żadnego z CVE nie było w CISA KEV w katalogu 2026.10.16. Niepotwierdzone: advisory nie podają numerów wydań NX-OS z poprawką (tylko Software Checker) ani domyślnego stanu NGOAM. Wyłączenie NX-API jako mitygacja i kolejność priorytetów to wnioski autora, nie zalecenia Cisco. Przed wdrożeniem sprawdź aktualne wersje advisory.