Cisco ostrzega przed krytycznym zero-dayem 9,8/10. Atakujący mogą uzyskać dostęp jako administrator

Cisco opublikowało pilne ostrzeżenie dotyczące krytycznej podatności CVE-2026-76504 w Cisco Catalyst SD-WAN Manager. Luka otrzymała ocenę CVSS 9,8 na 10 i pozwala zdalnemu napastnikowi ominąć mechanizm uwierzytelniania bez wcześniejszego dostępu do systemu. Po skutecznym ataku możliwe jest uzyskanie dostępu do API z uprawnieniami użytkownika administracyjnego.

To nie jest podatność odkryta wyłącznie podczas laboratoryjnych testów. Cisco potwierdziło, że jego zespół Product Security Incident Response Team dowiedział się o aktywnym wykorzystywaniu luki już we wrześniu 2026 roku. Firma nie podała jednak dokładnej daty rozpoczęcia ataków ani informacji o ich skali.

Publiczne ostrzeżenie zostało opublikowane 30 września 2026 roku o godz. 13:00 GMT, czyli 15:00 czasu polskiego CEST. Cisco udostępniło jednocześnie poprawione wersje oprogramowania i zaleca ich natychmiastową instalację. Nie istnieje obejście konfiguracyjne, które całkowicie usuwałoby podatność.

CVE-2026-76504 pozwala ominąć uwierzytelnianie Cisco SD-WAN Manager

Problem znajduje się w mechanizmie uwierzytelniania sesyjnego API Cisco Catalyst SD-WAN Manager. Według Cisco podatność wynika z nieprawidłowego przetwarzania kodowania URI w żądaniu HTTP, przez co odpowiednio przygotowane zapytanie może ominąć regułę uwierzytelniania chroniącą określony endpoint API.

Atakujący może więc wysłać specjalnie spreparowane żądanie HTTP bez wcześniejszego zalogowania się do systemu. Nie musi wcześniej przejąć konta użytkownika, znać hasła administratora ani skłonić pracownika do kliknięcia linku. Po udanym wykorzystaniu podatności może uzyskać dostęp do API jako użytkownik admin.

Właśnie dlatego luka otrzymała niemal maksymalną ocenę 9,8 w skali CVSS 3.1. Atak jest możliwy przez sieć, ma niską złożoność, nie wymaga wcześniejszych uprawnień ani interakcji użytkownika, a potencjalny wpływ na poufność, integralność i dostępność systemu jest wysoki.

Mechanizm przypomina pod pewnymi względami krytyczną podatność CVE-2026-41940 w cPanel/WHM, którą również można było wykorzystać do obejścia standardowego procesu uwierzytelniania. W przypadku Cisco problem jest szczególnie poważny dlatego, że podatny system odpowiada za centralne zarządzanie infrastrukturą SD-WAN.

Cisco ujawniło lukę 30 września. Ataki trwały już wcześniej

Chronologia jest tutaj bardzo ważna. Cisco opublikowało oficjalne ostrzeżenie dotyczące CVE-2026-76504 30 września 2026 roku o godz. 13:00 GMT, czyli o 15:00 czasu polskiego. Była to pierwsza publiczna wersja advisory oznaczona jako 1.0.

Firma potwierdza jednak, że jej zespół PSIRT już wcześniej, we wrześniu 2026 roku, dowiedział się o aktywnym wykorzystywaniu podatności. Cisco nie podało dokładnego dnia, w którym rozpoczęły się ataki, ani momentu, w którym pojawiła się pierwsza znana kompromitacja. Nie wiadomo również publicznie, ile organizacji zostało zaatakowanych przed udostępnieniem poprawki.

To właśnie ten element sprawia, że CVE-2026-76504 można określać jako zero-day wykorzystywany przed publicznym ujawnieniem i udostępnieniem poprawionych wersji. Nie należy natomiast przypisywać atakom konkretnej daty tylko na podstawie przykładów umieszczonych przez Cisco w dokumentacji.

Producent pokazuje między innymi przykładowy wpis w logu z 29 września 2026 roku, godz. 23:11:13 w strefie -05:00, zawierający podejrzane żądanie /%6a_security_check. Cisco wyraźnie opisuje jednak ten zapis jako przykład wskaźnika kompromitacji, a nie potwierdzony moment pierwszego ataku. Data z przykładowego logu nie może więc być traktowana jako oficjalna data rozpoczęcia kampanii.

Luka została odkryta podczas obsługi prawdziwego zgłoszenia

CVE-2026-76504 nie została znaleziona podczas zwykłego audytu kodu czy planowanych testów penetracyjnych. Cisco informuje, że podatność została odkryta podczas rozwiązywania zgłoszenia obsługiwanego przez Cisco Technical Assistance Center, czyli TAC.

W połączeniu z potwierdzoną aktywną eksploatacją sugeruje to, że problem został zauważony w kontekście rzeczywistego środowiska klienta. Cisco nie podaje jednak szczegółów samego incydentu, nie ujawnia nazwy organizacji ani nie opisuje publicznie sposobu, w jaki napastnicy trafili na podatność.

Firma ogranicza komunikat do informacji, że PSIRT dowiedział się o aktywnej eksploatacji we wrześniu i zdecydowanie zaleca przejście na poprawione wydania. To wystarczający sygnał, aby administratorzy nie traktowali CVE-2026-76504 jak kolejnego błędu, który można załatać przy najbliższym planowanym oknie serwisowym.

W przypadku aktywnie wykorzystywanych podatności czas ma szczególne znaczenie. Gdy luka staje się publiczna, jej szczegóły mogą być analizowane także przez kolejnych atakujących, dlatego liczba prób wykorzystania podatności może wzrosnąć już po publikacji ostrzeżenia.

Dlaczego przejęcie Cisco Catalyst SD-WAN Manager jest tak poważne?

Cisco Catalyst SD-WAN Manager nie jest zwykłym panelem do konfiguracji pojedynczego urządzenia. To centralna platforma służąca do zarządzania środowiskiem SD-WAN, monitorowania infrastruktury, wdrażania konfiguracji i obsługi wielu elementów sieci rozproszonej pomiędzy różnymi lokalizacjami organizacji.

Uzyskanie dostępu administracyjnego do takiej warstwy zarządzającej może więc mieć znacznie większe znaczenie niż przejęcie zwykłego konta użytkownika. Napastnik trafia do systemu znajdującego się bardzo blisko centralnego punktu sterowania infrastrukturą sieciową, dlatego potencjalnego incydentu nie należy analizować jak włamania do pojedynczego komputera.

Cisco podkreśla przy tym, że podatność dotyczy samego Catalyst SD-WAN Manager, czyli vManage. Aby usunąć CVE-2026-76504, nie trzeba z tego powodu aktualizować Controllerów, Validatorów ani routerów brzegowych. Po zmianie wersji Managera należy jednak sprawdzić kompatybilność pozostałych elementów infrastruktury.

Sama obecność podatnej wersji również nie oznacza automatycznie, że system został zaatakowany. Cisco rozdziela dwa problemy: załatanie podatności oraz ustalenie, czy przed aktualizacją doszło już do kompromitacji.

Luka Cisco ma znaczenie również w Polsce

Cisco SD-WAN nie jest rozwiązaniem wykorzystywanym wyłącznie przez amerykańskie korporacje. Technologia jest obecna także w dużych polskich przedsiębiorstwach, szczególnie tam, gdzie trzeba centralnie zarządzać siecią obejmującą wiele oddziałów, sklepów lub zakładów.

Jednym z największych przykładów jest wdrożenie zrealizowane dla Żabki. Cisco informowało w 2023 roku, że system SD-WAN objął niemal 10 tys. sklepów w Polsce i był wówczas największym na świecie wdrożeniem Cisco SD-WAN działającym na jednej platformie technologicznej. Z rozwiązania korzystały również inne przedsiębiorstwa działające w Polsce, w tym Pfeifer & Langen Polska.

Nie oznacza to, że te konkretne sieci są podatne na CVE-2026-76504, ponieważ zależy to między innymi od używanej wersji Cisco Catalyst SD-WAN Manager oraz aktualnego sposobu zabezpieczenia infrastruktury. Pokazuje jednak, że ostrzeżenie Cisco nie jest dla polskich administratorów abstrakcyjnym problemem dotyczącym infrastruktury używanej wyłącznie za granicą.

Systemy dostępne z internetu są szczególnie narażone

Cisco wprost zwraca uwagę na Catalyst SD-WAN Manager wystawiony do internetu. Jeżeli podatny system posiada porty dostępne z publicznej sieci, znajduje się w grupie podwyższonego ryzyka, ponieważ napastnik może próbować dotrzeć bezpośrednio do interfejsu umożliwiającego wykorzystanie podatności.

Producent zaleca ograniczenie dostępu z niezaufanych sieci oraz przepuszczanie ruchu administracyjnego wyłącznie z wcześniej zatwierdzonych hostów. Komponenty sterujące SD-WAN powinny znajdować się za firewallem lub innym urządzeniem filtrującym, które ogranicza dostęp do niezbędnych portów i protokołów.

To jednak tylko działanie ograniczające ryzyko. Cisco wyraźnie zaznacza, że nie istnieje workaround usuwający CVE-2026-76504. Ograniczenie dostępu z internetu może znacząco zmniejszyć powierzchnię ataku, ale nie naprawia samego błędu w oprogramowaniu.

Podobna zasada obowiązuje zresztą także w znacznie mniejszych sieciach. W naszym poradniku wyjaśniającym, jak bezpiecznie skonfigurować router, zwracaliśmy uwagę na wyłączanie niepotrzebnego zdalnego zarządzania i ograniczanie dostępu do interfejsów administracyjnych. W środowisku korporacyjnym znaczenie tych zasad jest jeszcze większe.

Cisco nie pozostawia wyboru: trzeba zaktualizować SD-WAN Manager

Oficjalne zalecenie producenta jest jednoznaczne. Wszystkie Cisco Catalyst SD-WAN Manager działające na wydaniu wcześniejszym niż pierwsza poprawiona wersja dla danej gałęzi należy zaktualizować możliwie szybko. Nie ma ustawienia ani zmiany konfiguracji, która mogłaby być traktowana jako pełnoprawny zamiennik instalacji poprawki.

Cisco opublikowało poprawione wydania dla wszystkich aktualnie obsługiwanych linii oprogramowania. Administrator nie powinien jednak przechodzić samodzielnie do nowszej głównej gałęzi tylko dlatego, że zawiera poprawkę. Producent zaleca pozostanie w obecnym major release i instalację odpowiedniej poprawionej wersji.

Cisco usunęło podatność również w zarządzanej usłudze Cisco SD-WAN Cloud w wydaniu 20.15.605. W tym konkretnym przypadku firma informuje, że klienci nie muszą wykonywać dodatkowej aktualizacji po swojej stronie.

Przed aktualizacją trzeba zachować dane diagnostyczne

Cisco opublikowało osobną procedurę naprawczą dla CVE-2026-76504 i kolejność działań ma tutaj znaczenie. Pierwszym krokiem jest zebranie plików admin-tech ze wszystkich Catalyst SD-WAN Manager przed rozpoczęciem aktualizacji. Dzięki temu administrator zachowuje dane potrzebne do późniejszego sprawdzenia, czy system nosi ślady wcześniejszego ataku.

Jeżeli środowisko korzysta z klastra, dane trzeba zebrać z każdego jego członka. To samo dotyczy instalacji Disaster Recovery – pliki powinny pochodzić ze wszystkich Managerów zarówno w podstawowej, jak i zapasowej lokalizacji. Cisco zaleca podczas generowania admin-tech wybranie danych Log i Tech, natomiast komponent Core nie jest wymagany.

Dopiero po zabezpieczeniu danych diagnostycznych należy rozpocząć aktualizację wszystkich Managerów do poprawionej wersji. Cisco wyraźnie ostrzega, aby nie czekać na analizę TAC przed wykonaniem aktualizacji. Zamknięcie podatności jest najwyższym priorytetem, natomiast sprawdzenie śladów kompromitacji odbywa się później.

To ważna różnica. Administrator najpierw zachowuje materiał diagnostyczny, następnie usuwa podatność, a dopiero potem czeka na wynik analizy. System nie powinien pozostawać podatny tylko dlatego, że trwa sprawdzanie logów.

Po aktualizacji Cisco zaleca otwarcie zgłoszenia TAC

Po przejściu na poprawione oprogramowanie Cisco zaleca otwarcie zgłoszenia w Technical Assistance Center i przesłanie wcześniej zebranych plików admin-tech. Zgłoszenie powinno mieć poziom Severity 3, a w jego tytule należy umieścić oznaczenie CVE-2026-76504.

TAC analizuje przekazane dane pod kątem wskaźników kompromitacji związanych konkretnie z tą podatnością. Jeśli nie zostaną znalezione ślady ataku, Cisco informuje, że nie są potrzebne dalsze działania związane z CVE-2026-76504 poza wykonaną już aktualizacją.

Jeżeli natomiast pojawią się wskaźniki kompromitacji, TAC kontaktuje się z klientem i przekazuje dalsze zalecenia dopasowane do konkretnego środowiska. Cisco podkreśla przy tym, że TAC nie wykonuje pełnej analizy forensic ani kompleksowego dochodzenia po incydencie. W bardziej rozbudowanej sprawie organizacja może potrzebować własnego zespołu bezpieczeństwa lub zewnętrznej firmy incident response.

Jeżeli z jakiegoś powodu nie można zebrać pakietów admin-tech, Cisco udostępnia także procedurę ręcznej weryfikacji. Producent nadal traktuje jednak zebranie pełnych danych diagnostycznych jako preferowaną metodę oceny środowiska.

Jak wyglądają ślady wykorzystania CVE-2026-76504?

Cisco wskazuje dwa główne miejsca, które administratorzy mogą sprawdzić podczas szukania potencjalnych oznak wykorzystania podatności. Pierwszym jest plik serviceproxy-access.log, gdzie należy zwrócić uwagę na wywołania związane z j_security_check pochodzące z nieznanych lub nieautoryzowanych adresów IP.

Przykład opublikowany przez Cisco pokazuje żądanie zawierające %6a_security_check. %6a jest kodowanym znakiem j, ale producent zaznacza, że nie należy szukać wyłącznie dokładnie takiej samej sekwencji. Podatność pozwala wykorzystać zakodowanie także innego pojedynczego znaku w żądaniu.

Drugim miejscem jest vmanage-server.log. Podejrzane mogą być wywołania j_security_check związane z kontami, których nazwy zaczynają się od viptela-reserved-, szczególnie jeśli pozostałe dane nie odpowiadają normalnej aktywności danego środowiska.

Same wpisy nie są jednak automatycznym dowodem włamania. Cisco ostrzega, że podobne zdarzenia mogą pojawiać się również podczas legalnych operacji, testów bezpieczeństwa czy działania autoryzowanych skanerów. Dlatego wskaźniki trzeba zestawić z normalnym ruchem w konkretnej sieci.

Przykładowy log z 29 września nie oznacza, że wtedy rozpoczęły się ataki

Ten szczegół łatwo źle zinterpretować. W dokumentacji Cisco znajduje się przykładowy wpis:

[2026-09-29T23:11:13.948-05:00] "POST /%6a_security_check HTTP/1.1"

Data może sugerować, że Cisco zna dokładny przypadek ataku z 29 września, ale producent nie przedstawia tego wpisu jako osi czasu rzeczywistej kampanii. Znajduje się on w sekcji prezentującej przykładowe Indicators of Compromise i służy administratorom do pokazania, jakiego rodzaju ruchu powinni szukać w swoich systemach.

Dlatego w przypadku CVE-2026-76504 możemy potwierdzić tylko dwie daty. Cisco dowiedziało się o aktywnej eksploatacji w bliżej nieokreślonym momencie września 2026 roku, natomiast podatność została publicznie ujawniona 30 września o 13:00 GMT, czyli 15:00 CEST.

Nie ma natomiast podstaw, aby twierdzić, że pierwsze ataki rozpoczęły się 29 września. Mogły zacząć się wcześniej, ale Cisco nie ujawniło tej informacji. W przypadku zero-dayów właśnie takie rozróżnienie jest ważne, bo przykładowy log techniczny bardzo łatwo zamienić w datę, której producent nigdy oficjalnie nie potwierdził.

CVSS 9,8/10 dobrze pokazuje skalę problemu

CVE-2026-76504 otrzymała wektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, który na pierwszy rzut oka wygląda jak ciąg technicznych skrótów. W praktyce opisuje jednak niemal najgorszą kombinację cech, jaką może mieć podatność dostępna w systemie sieciowym.

Atak jest możliwy zdalnie przez sieć i ma niską złożoność. Napastnik nie potrzebuje żadnych wcześniejszych uprawnień, a użytkownik nie musi wykonywać dodatkowej czynności. Potencjalne konsekwencje dla poufności danych, ich integralności oraz dostępności usługi zostały ocenione jako wysokie.

Sama liczba 9,8 nie jest jednak najważniejszym argumentem za pilną aktualizacją. Znacznie istotniejsze jest potwierdzenie aktywnej eksploatacji jeszcze przed publicznym ujawnieniem podatności. Nawet luka o nieco niższym CVSS może być w praktyce bardziej niebezpieczna, jeśli napastnicy mają już działającą metodę jej wykorzystywania.

Rosną też możliwości automatycznego wyszukiwania błędów. Niedawno opisywaliśmy na Techotece, jak OpenAI Astra potrafi samodzielnie znajdować podatności zero-day i budować łańcuchy exploitów. Dla administratorów oznacza to jeszcze większą presję na szybkie instalowanie poprawek po ujawnieniu krytycznych podatności.

Sama aktualizacja nie wystarczy, jeśli ktoś wszedł wcześniej

Najważniejsza rzecz przy aktywnie wykorzystywanym zero-dayu jest prosta: poprawka chroni przed kolejną próbą wykorzystania podatności, ale nie cofa działań wykonanych przez napastnika przed jej instalacją. Dlatego Cisco nie kończy procedury na komunikacie „zaktualizuj system”.

Najpierw administrator powinien zachować admin-tech ze wszystkich Managerów. Następnie musi zaktualizować środowisko do jednej z bezpiecznych wersji, bez czekania na analizę TAC. Dopiero później przychodzi czas na ocenę, czy w systemie widać ślady wcześniejszego wykorzystania CVE-2026-76504.

Jeśli takie ślady istnieją, zakres reakcji zależy od tego, co faktycznie zrobił napastnik. Samo zamknięcie podatności nie daje wtedy gwarancji, że w środowisku nie pozostawiono innych sposobów dostępu albo nie zmieniono konfiguracji. W takiej sytuacji potrzebna może być znacznie szersza analiza incydentu.

To właśnie odróżnia zwykłą aktualizację bezpieczeństwa od reakcji na zero-day, który już był wykorzystywany. Trzeba jednocześnie zamknąć wejście i sprawdzić, czy ktoś nie zdążył przejść przez nie wcześniej.

Administratorzy Cisco SD-WAN nie powinni z tym czekać

CVE-2026-76504 łączy kilka cech, które razem tworzą bardzo niebezpieczny scenariusz: zdalny atak, brak konieczności uwierzytelnienia, niska złożoność wykorzystania, możliwość uzyskania dostępu jako administrator oraz oficjalnie potwierdzona aktywna eksploatacja.

Cisco ujawniło podatność 30 września 2026 roku o godz. 15:00 czasu polskiego, ale napastnicy korzystali z niej już wcześniej. Nie wiadomo dokładnie, od kiedy, ponieważ producent ograniczył tę informację do stwierdzenia, że PSIRT dowiedział się o aktywnych atakach we wrześniu.

Dla administratorów procedura jest więc jasno określona: zebrać dane admin-tech ze wszystkich Managerów, natychmiast przejść do poprawionej wersji i następnie przekazać dane do TAC w celu sprawdzenia wskaźników kompromitacji. Ograniczenie dostępu do systemu z internetu jest dobrym zabezpieczeniem dodatkowym, ale nie zastępuje poprawki.

W tym przypadku czekanie na „spokojniejsze okno serwisowe” oznacza pozostawienie aktywnie wykorzystywanej podatności w systemie odpowiedzialnym za zarządzanie infrastrukturą sieciową. Cisco nie pozostawia tu większego pola do interpretacji: aktualizacja powinna zostać potraktowana jako zadanie pilne.

Źródła: Cisco. Opracowanie własne.

Dziękujemy za przeczytanie artykułu na Techoteka.pl.
Codziennie publikujemy najważniejsze informacje z Polski i ze świata dotyczące technologii, sztucznej inteligencji, nowych rozwiązań cyfrowych oraz trendów technologicznych, które kształtują przyszłość.
Obserwuj nas na Facebooku, aby być na bieżąco z najważniejszymi wydarzeniami ze świata technologii.