Formularz do wgrywania pliku wygląda niewinnie i dlatego rzadko trafia na listę rzeczy do sprawdzenia. Usterka oznaczona numerem CVE-2026-20262 pokazuje, co się dzieje, gdy taki formularz przyjmuje nie tylko plik, ale też informację, gdzie go zapisać. Ten wpis wyjaśnia, na czym polega ta sztuczka, dlaczego usterka z oceną średnią trafiła tego samego dnia na listę spraw pilnych, kto w firmie realnie może ją wykorzystać i po jakich śladach w dziennikach poznać, że ktoś już próbował.
Plik wgrany do katalogu, o który nikt nie prosił
Usterka siedzi w interfejsie przeglądarkowym Cisco Catalyst SD-WAN Manager, oprogramowania zarządzającego siecią rozpiętą między lokalizacjami firmy, wcześniej znanego pod nazwą vManage. Przyczyną jest brak sprawdzania danych podanych przez użytkownika podczas wgrywania pliku.
Sam trik ma nazwę własną i katalog typów usterek prowadzi go pod numerem CWE-22, jako przejście po ścieżce katalogów. Działa tak: program zapisuje wgrany plik pod nazwą podaną przez użytkownika, a użytkownik zamiast zwykłej nazwy podaje nazwę zawierającą sekwencje dwóch kropek i ukośnika. Każda taka sekwencja oznacza dla systemu plików polecenie "wróć o jeden katalog wyżej". Wystarczy powtórzyć ją odpowiednią liczbę razy, żeby wyjść z folderu przeznaczonego na wgrywane pliki i trafić w dowolne inne miejsce na dysku serwera.
Skutkiem jest utworzenie albo nadpisanie dowolnego pliku w systemie plików urządzenia. Nadpisanie bywa gorsze niż utworzenie, bo pozwala podmienić plik, któremu system ufa.
Dla firmy najbardziej praktyczny wniosek dotyczy nie tego konkretnego panelu, tylko sposobu myślenia o funkcjach wgrywania. Każde miejsce, w którym system przyjmuje plik od człowieka, przyjmuje też jego nazwę, a nazwa bywa poleceniem. Zamiast pytać, czy ktoś może wgrać niebezpieczny plik, warto pytać, gdzie ten plik wyląduje i kto to miejsce wybiera.
Od zapisanego pliku do panowania nad serwerem
Zapis pliku sam w sobie brzmi łagodnie, dopóki nie doda się drugiej części zdania z komunikatu producenta: zapisany plik może posłużyć do podniesienia uprawnień do konta administratora systemu.
Wskaźniki opublikowane przez producenta pokazują, jak wyglądało to w praktyce. W dzienniku serwera pojawia się wpis o wgraniu profilu dostępu zdalnego, w którym ścieżka zawiera sekwencje wychodzące o poziom wyżej i prowadzi do katalogu wdrożeń serwera aplikacji. Następnie w kolejnym dzienniku widać wdrożenie pakietu aplikacji, a w trzecim żądanie wysłane do wgranego pliku wykonywalnego. To jest opis podstawienia własnej aplikacji na serwer i uruchomienia jej przez zwykłe wywołanie z przeglądarki.
Przełożenie na sytuację firmy jest bezpośrednie. Serwer zarządzający siecią zaczyna hostować aplikację, której nikt nie zamawiał i której nie ma w żadnej dokumentacji wdrożenia. Firma produkcyjna z trzema zakładami odczuje to najwcześniej jako dziwne obciążenie serwera albo zmiany konfiguracji, których nikt nie zgłaszał. Zamiast liczyć na przypadkowe zauważenie, warto raz spisać, jakie aplikacje mają prawo działać na serwerze zarządzającym, bo lista złożona z kilku pozycji sprawia, że pozycja dodatkowa rzuca się w oczy.
Kto w firmie może to wykorzystać
Tutaj kryje się szczegół, który zmieniał się w trakcie. Producent doprecyzował w poprawionej wersji komunikatu, że napastnik musi mieć ważne dane logowania z co najmniej prawem zapisu. Pierwotna wersja mówiła o koncie o niskich uprawnieniach, przeznaczonym do pojedynczego zadania, i taki właśnie opis nadal widnieje w amerykańskiej bazie podatności.
Praktyczna różnica jest większa, niż wygląda. Przy pierwszym opisie zagrożeniem jest każde konto, także najbardziej ograniczone. Przy drugim liczy się jedno kryterium: czy konto ma prawo zapisu. Obie wersje prowadzą jednak do tego samego zadania po stronie firmy, czyli do przejrzenia listy kont mających dostęp do panelu zarządzania siecią.
Ta lista bywa zaskakująco długa i rzadko ktokolwiek ją czyta. Znajdują się na niej konta byłych pracowników, konta założone dla firmy wdrożeniowej na czas projektu sprzed trzech lat, konta techniczne używane przez inne systemy do pobierania danych. Firma budowlana, która zmieniła dostawcę usług informatycznych, ale nie odebrała starych dostępów, ma tu problem niezależny od jakiejkolwiek usterki. Zamiast czekać na kolejny komunikat producenta, warto raz na kwartał przejrzeć konta w panelu i skasować te, do których nikt nie potrafi przypisać żywej osoby albo działającego systemu.
Ocena średnia, a termin liczony w dniach
Producent ocenił tę usterkę na 6.5 w skali CVSS, gdzie dziesięć to sytuacja najgorsza, i przypisał jej wagę średnią. Trzy rzeczy obniżają wynik: napastnik musi mieć jakieś uprawnienia, poufność danych nie jest bezpośrednio naruszona, dostępność usługi też nie. Naruszona jest integralność, i to w stopniu wysokim.
Mimo tej średniej oceny amerykańska agencja do spraw cyberbezpieczeństwa wpisała usterkę do katalogu podatności wykorzystywanych w rzeczywistych atakach 15 czerwca 2026, czyli tego samego dnia, w którym producent opublikował komunikat, i wyznaczyła termin naprawy na 29 czerwca. Katalog ten obejmuje wyłącznie usterki, o których wiadomo, że ktoś ich naprawdę używa, a nie takie, których użycie jest teoretycznie możliwe.
Tomasz Kaczmarek
Mogę Ci jakoś pomóc?
Zestawienie oceny średniej z wpisem do tego katalogu jest właśnie tą informacją, która ma największą wartość praktyczną. Ocena punktowa mówi, jak groźna jest usterka w oderwaniu od świata. Katalog mówi, że ktoś już z niej korzysta. Firma, która sortuje zadania wyłącznie według oceny punktowej, ustawi ten przypadek za wieloma innymi, groźniejszymi na papierze i nieużywanymi w praktyce.
Wskaźnik EPSS, szacujący szansę wykorzystania usterki w najbliższym miesiącu, wynosi tu około 0,28, co brzmi nisko, ale plasuje ją wyżej niż ponad dziewięćdziesiąt osiem procent wszystkich znanych podatności. Ocena wykonana przez tę samą agencję określa wykorzystywanie jako aktywne, ale zaznacza, że atak nie daje się zautomatyzować i że skutek techniczny jest częściowy. To tłumaczy, dlaczego termin wyniósł dwa tygodnie, a nie trzy dni jak przy usterkach, które da się masowo skanować.
Wersje, ślady i brak obejścia
Obejścia nie ma i producent stwierdza to wprost. Pierwsze naprawione wydania to 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1 oraz 26.1.1.2. Usterka dotyczy panelu niezależnie od jego ustawień i obejmuje wszystkie rodzaje wdrożenia: instalacje własne, warianty chmurowe oraz wersję przeznaczoną dla administracji publicznej.
Warto odnotować, skąd wzięła się wiedza o tej usterce. Znalazł ją sam producent podczas własnych testów bezpieczeństwa, a o ograniczonym wykorzystywaniu w atakach dowiedział się w czerwcu 2026.
Ślady ewentualnego ataku rozkładają się na trzy różne dzienniki: jeden pokazuje wgranie pliku ze ścieżką wychodzącą poza katalog, drugi wdrożenie pakietu aplikacji, trzeci żądanie wysłane do podstawionego pliku. Dla firmy oznacza to, że sprawdzenie nie polega na przejrzeniu jednego pliku, tylko na zestawieniu trzech. Jeśli dzienniki są kasowane po tygodniu albo nikt nie wie, gdzie leżą, to pytanie o to, czy ktoś próbował, zostaje bez odpowiedzi.
Kolejność działania jest tu prosta i warto ją zapamiętać niezależnie od tego konkretnego przypadku: najpierw zabezpieczenie dzienników, potem aktualizacja, na końcu przegląd kont z prawem zapisu. Odwrotna kolejność zamyka drzwi, ale zostawia w środku pytanie bez odpowiedzi.