Cisco SD-WAN pod atakiem: CVE-2026-20127 i krytyczny klaster Managera

25 lutego 2026 roku Cisco opublikowało poprawki dla dwóch powiązanych obszarów Catalyst SD-WAN. CVE-2026-20127 otrzymała maksymalny wynik CVSS 10,0: nieuwierzytelniony napastnik mógł przez przygotowane żądania uzyskać wewnętrzne konto o wysokich uprawnieniach, dostać się do NETCONF i modyfikować konfigurację fabric. Osobny advisory Managera objął pięć niezależnych luk, w tym obejście uwierzytelniania API CVE-2026-20129 z CVSS 9,8. Cisco później potwierdziło aktywne wykorzystanie części tego klastra.

Nie jest to „jedna dziura w panelu”. Pierwszy problem dotyczy uwierzytelniania peeringu pomiędzy rolami kontrolnymi — Controller/vSmart, Manager/vManage i Validator/vBond. Drugi zestaw obejmuje różne granice zaufania w Managerze: API, lokalny REST, ujawnienie informacji i ścieżki prowadzące do podwyższenia uprawnień. Ich wspólnym mianownikiem jest kontrola płaszczyzny zarządzania siecią rozległą.

Dlaczego wpływ wykracza poza pojedynczy serwer

SD-WAN Manager nie zarządza zwykłą aplikacją. Utrzymuje polityki, topologię, konfigurację edge’ów, szablony i relacje z kontrolerami. Dostęp do fabric może umożliwić zmianę routingu, segmentacji, polityk bezpieczeństwa lub parametrów urządzeń w wielu lokalizacjach. Nawet konto opisane jako „high-privileged non-root” ma znaczenie, jeśli jego funkcja pozwala wykonywać operacje sieciowe o skali przedsiębiorstwa.

CVE-2026-20127 wykorzystuje błąd w mechanizmie uwierzytelniania peeringu. Według Cisco przygotowane żądania prowadzą do dostępu jako wewnętrzny użytkownik vmanage-admin, a następnie do interfejsu NETCONF. NETCONF jest legalnym protokołem zarządzania opartym na RPC i modelach danych; sam nie jest podatnością. Problem polega na tym, że napastnik bez praw uzyskuje tożsamość, której protokół ufa.

Klaster Managera jest niezależny od CVE-2026-20127. CVE-2026-20129 pozwala nieuwierzytelnionemu napastnikowi ominąć kontrolę API i uzyskać rolę netadmin. CVE-2026-20126 umożliwia lokalnemu użytkownikowi o niskich uprawnieniach przejście przez REST API do roota. CVE-2026-20133 dotyczy ujawnienia informacji. Cisco wskazało aktywne wykorzystanie CVE-2026-20128 i CVE-2026-20122 w marcu oraz CVE-2026-20133 w kwietniu. Daty i numery trzeba zachować osobno; nie każda luka miała identyczny status w dniu publikacji.

Zakres: on-premises, cloud i FedRAMP

Advisory CVE-2026-20127 obejmuje wdrożenia lokalne oraz warianty hostowane przez Cisco, w tym środowiska cloud i FedRAMP. W modelu współdzielonej odpowiedzialności nie wolno zakładać, że „SaaS aktualizuje się samo”, ani że klient może samodzielnie zainstalować poprawkę. Właściciel usługi powinien uzyskać od dostawcy dowód wersji i czasu remediacji, a równolegle przejrzeć własne logi, tożsamości, integracje i zmiany konfiguracji.

Cisco nie podało obejścia zastępującego aktualizację. Segmentacja, ACL i ograniczenie portów zmniejszają powierzchnię, ale nie naprawiają błędnej logiki uwierzytelniania. Każdą rolę trzeba przypisać do właściwej tabeli wersji w advisory; podobna nazwa wydania nie jest wystarczającym dowodem.

Ślady, których należy szukać

Cisco zaleca przegląd /var/log/auth.log pod kątem wpisów Accepted publickey for vmanage-admin z nieznanego adresu. Jest to konkretny i wartościowy trop, lecz nie kompletna reguła detekcji. Należy uwzględnić retencję, rotację logów, strefę czasową, NAT i adresy systemów automatyzacji. Znany adres źródłowy również nie gwarantuje legalności, jeśli bastion albo runner został przejęty.

Korelacja powinna objąć:

• nowe sesje lub klucze vmanage-admin i netadmin;
• zdarzenia peeringu poza oknem zmian;
• nietypowe operacje NETCONF i REST;
• modyfikacje szablonów, policy lists, device templates i routingu;
• nagłe operacje na wielu urządzeniach edge;
• tworzenie użytkowników, zmianę RBAC i eksport konfiguracji;
• luki w zewnętrznym logowaniu albo zmianę celu syslog.

Przed aktualizacją wyeksportuj logi do systemu niezależnego od Managera. Jeżeli płaszczyzna zarządzania została przejęta, jej lokalna telemetria nie może być jedynym źródłem prawdy.

Priorytet remediacji

Najpierw identyfikujemy instancje internet-facing i porty kontrolne. Następnie potwierdzamy role, wersje oraz to, czy zarządzanie jest osiągalne z sieci użytkowników, partnerów lub chmury. Aktualizacja obejmuje cały kompatybilny zestaw komponentów, nie tylko UI Managera. Po zmianie trzeba przetestować peering, dystrybucję polityk, failover i spójność konfiguracji.

Praktyczny plan:

1. zamrozić niekrytyczne zmiany i zabezpieczyć zewnętrzne logi;
2. ograniczyć kontrolne i administracyjne porty do jawnych źródeł;
3. zainstalować poprawione wersje według obu advisory Cisco;
4. unieważnić nieznane klucze i przejrzeć konta wewnętrzne;
5. porównać szablony i polityki z repozytorium konfiguracji;
6. zbadać każdy nieautoryzowany login jako potencjalną zmianę całej fabric;
7. po aktualizacji wykonać negatywny test dostępu i kontrolowany failover.

Cisco rekomenduje również zewnętrzne logowanie, wyłączenie niepotrzebnego HTTP/FTP i zastosowanie przewodnika hardeningu. Są to działania trwałe, które ograniczają kolejny błąd, ale nie powinny opóźniać patchowania.

Lekcja dla bezpieczeństwa płaszczyzny zarządzania

System orkiestrujący sieć jest zasobem poziomu krytycznego. Powinien mieć dedykowaną strefę, oddzielne tożsamości, administrację przez bastion, MFA tam, gdzie wspierane, niezmienialne kopie konfiguracji i logowanie poza własną domenę zaufania. Dostęp API oraz automatyzacja muszą mieć taki sam poziom kontroli jak GUI.

Dodaj Cisco SD-WAN do inwentaryzacji zewnętrznej powierzchni ataku, priorytetyzuj za pomocą procesu podatności i buduj korelacje zgodnie z detection engineering. W sprawie bezpiecznej walidacji konfiguracji i segmentacji skontaktuj się z BreachRoad.

---

Źródła pierwotne: Cisco — CVE-2026-20127, Cisco — klaster Catalyst SD-WAN Manager.