3 września 2026 MikroTik opublikował biuletyn, w którym napisał: „Most configurations are not at risk, but upgrading is highly recommended”. Według ustaleń CERT Polska udane ataki z wykorzystaniem tych właśnie błędów trwały już od 2 września. Dzień później Shadowserver naliczył 122 500 urządzeń MikroTik z usługą SSH dostępną z internetu.
Co się właściwie zmieniło
Zespół CERT Polska zidentyfikował i skoordynował ujawnienie sześciu podatności w RouterOS. Dwie z nich, połączone w łańcuch nazwany MikroTrick, pozwalają przejąć pełną kontrolę nad urządzeniem bez uwierzytelniania — pod warunkiem, że SSH jest osiągalny z sieci atakującego. Poprawki trafiły do wydań 7.25beta3, 7.24.2, 7.23.4 oraz 6.49.21.
10 września CISA dopisała do katalogu znanych wykorzystywanych podatności dwie pozycje: CVE-2026-86060 i CVE-2026-67277. Formalnie katalog wiąże tylko amerykańskie agencje federalne, ale jego zawartość jest najlepszym publicznym wskaźnikiem tego, co realnie jest używane w atakach — a nie tylko teoretycznie wykorzystywalne.
Szczegóły techniczne CERT Polska opisał w ostrzeżeniu z 5 września, jawnie tłumacząc, dlaczego zdecydował się na przyspieszoną publikację: poprawione pakiety były już publiczne, a ich analiza porównawcza pozwoliła społeczności odtworzyć część usuniętych błędów. Milczenie po wypuszczeniu łatki nie chroni już nikogo poza producentem.
Dwa błędy, które razem dają administratora bez hasła
Pierwszy element łańcucha to CVE-2026-67276 (CVSS 9.2). RouterOS nieprawidłowo weryfikował klucze publiczne przy uwierzytelnianiu SSH — nie porównywał całego klucza RSA przypisanego użytkownikowi. Atakujący znający nazwę konta i publiczny moduł jego klucza mógł spreparować inny klucz i zalogować się bez posiadania klucza prywatnego. To błąd klasy CWE-347: niepoprawna weryfikacja podpisu kryptograficznego. Nie obejście uwierzytelniania przez przepełnienie bufora, tylko niedokończone porównanie.
Drugi to CVE-2026-86060 (CVSS 9.2). RouterOS nieprawidłowo obsługiwał nazwy użytkowników zaczynające się od niedozwolonego znaku. Spreparowana nazwa pozwalała na eskalację — uzyskana sesja miała pełne uprawnienia administracyjne. Ślad w dzienniku jest charakterystyczny: wpisy login failure for user -2 oraz user <nazwa> added by ssh:-2@<ip>.
Trzecia podatność, CVE-2026-67277 (CVSS 8.8 według CERT Polska), dotyczy usługi bandwidth-test: nieuwierzytelnione połączenie mogło wejść w stan zarezerwowany dla zalogowanych, co w połączeniu z ujawnieniem niezainicjalizowanego bufora pakietów i błędem integer underflow dawało wyciek pamięci jądra albo restart urządzenia.
CERT Polska podaje konkretne adresy: udane ataki i zakładanie wysoko uprzywilejowanego konta „ops” prowadzono z 82.192.72.4 co najmniej od 2 września; z 103.102.31.18 szły próby eksploitacji.
Komunikat producenta, który się nie zgadza z faktami
Biuletyn MikroTika mówi o „podatności” w liczbie pojedynczej, zapowiada wstrzymanie szczegółów, żeby dać czas na aktualizację, i uspokaja: „For regular home device users the issue does not pose an immediate risk”. W tym samym czasie sześć błędów było już naprawionych, dwa z nich w łańcuchu dawały roota bez hasła, a kampania działała od poprzedniego dnia. To nie jest kwestia niefortunnego sformułowania. To decyzja komunikacyjna, która przesuwa ciężar oceny ryzyka na administratora, jednocześnie odmawiając mu danych potrzebnych do tej oceny.
Producent dodał za to mechanizm, którego wcześniej nie było: podczas startu RouterOS analizuje konfigurację pod kątem znanych śladów nieautoryzowanych zmian, wyłącza podejrzane wpisy, zapisuje krytyczny komunikat w logu i ustawia znacznik „Flagged”. Rozwiązanie sensowne — i połowiczne, co CERT Polska nazywa wprost: mechanizm wykrywa jedynie wybrane ślady, a brak flagi nie jest dowodem, że urządzenie jest bezpieczne. Jeżeli atakujący posprzątał po sobie inaczej, niż przewidziano w sygnaturach, router wstanie czysty i zielony.
Warto też odnotować rzecz, która w tej branży zdarza się rzadko: MikroTik po raz pierwszy w historii wysłał powiadomienie push na telefony użytkowników aplikacji mobilnej. Kanał dotarcia poprawiono. Treść przekazu — nie.
Podatności znalazł model. Pod ścisłym nadzorem człowieka
Najciekawszy fragment ostrzeżenia nie dotyczy RouterOS. Podatności odnalazł Sławomir Rozbicki z CERT Polska przy użyciu modeli GPT-5.5-cyber i GPT-5.6-sol, w ramach dostępu do programu OpenAI GTAC. Agent automatyzował tworzenie i przywracanie maszyn laboratoryjnych, pobieranie i porównywanie wersji, analizę RFC oraz kodu binarnego. Szczególnie skuteczne okazało się modelowanie protokołów jako maszyn stanów i sprawdzanie, co się stanie po pominięciu, powtórzeniu albo przestawieniu etapu.
CERT Polska od razu ucina narrację o magii: „Nie był to jednak rezultat pojedynczej instrukcji (promptu)”. Każda hipoteza wymagała potwierdzenia na rzeczywistym RouterOS, testów kontrolnych, powtórzenia na czystym stanie maszyny i oceny wpływu przez badaczy. Najbardziej pracochłonne pozostały: przygotowanie kontekstu, projekt bezpiecznego laboratorium, wybór kierunków i pełna weryfikacja wyników.
To jest realistyczny obraz tego, co model dziś robi w badaniu bezpieczeństwa: skraca czas eksploracji hipotez, nie zastępuje ani laboratorium, ani oceny. I działa symetrycznie — ta sama przewaga czasowa jest dostępna drugiej stronie, przy znacznie luźniejszym reżimie weryfikacji.
Co z tego wynika dla polskiej organizacji?
RouterOS jest w Polsce sprzętem domyślnym w segmencie, o którym nikt nie pisze raportów: małe i średnie firmy, gabinety, sieci osiedlowe, oddziały, biura obsługiwane przez zewnętrznego informatyka. Urządzenie kosztuje kilkaset złotych, działa latami i nie ma właściciela w sensie procesowym — jest „ten router”. Kampania, która wymaga wyłącznie osiągalnego SSH, uderza dokładnie w tę populację, bo tam port zarządzania wystawiano świadomie, żeby dało się wejść zdalnie bez VPN-a.
Dochodzi do tego kontekst regulacyjny. Podmioty objęte znowelizowaną ustawą o KSC mają obowiązek wpisu do Wykazu KSC do 3 października 2026, a pełne obowiązki — w tym zgłaszanie incydentów do właściwego CSIRT i wdrożony SZBI — do 3 kwietnia 2027. Przejęty router brzegowy w podmiocie kluczowym albo ważnym przestaje być kłopotem technicznym i staje się incydentem podlegającym zgłoszeniu. Organizacja, która nie wie, ile ma RouterOS-ów i w jakich wersjach, nie jest w stanie ani stwierdzić, czy incydent wystąpił, ani udokumentować, że go nie było.
Jeżeli szukasz punktu wyjścia po stronie systemów, które te routery obsługują, opisaliśmy wcześniej hardening Windows Server — ta sama zasada ograniczania powierzchni zarządzania obowiązuje po obu stronach brzegu.
- Zinwentaryzuj RouterOS-y po wersji, nie po nazwie. Wykonaj /system resource print na każdym urządzeniu i porównaj z progami: bezpieczne są 7.24.2, 7.23.4, 6.49.21 i nowsze w danej gałęzi. Urządzenia u klientów i w oddziałach, o których „ktoś kiedyś” zapomniał, są dokładnie tą populacją, w którą uderza kampania.
- Po aktualizacji sprawdź trzy rzeczy, w tej kolejności: wynik /system/device-mode/print pod kątem znacznika flagged, listę użytkowników pod kątem konta „ops” i innych nieznanych kont, oraz harmonogram, skrypty, serwery proxy i tunele. Brak znacznika nie kończy kontroli — kończy ją dopiero przejrzenie konfiguracji.
- Zamknij SSH i WebFig od strony internetu na stałe, nie na czas incydentu. Zarządzanie brzegiem przez publicznie wystawiony port jest decyzją architektoniczną, nie przypadkiem — zastąp je tunelem (WireGuard) i regułą ograniczającą dostęp do adresów sieci zarządzającej. Jeżeli urządzenie nosi ślady kompromitacji: izolacja, zabezpieczenie logów i konfiguracji przed resetem, reset do ustawień fabrycznych, odbudowa z zaufanej konfiguracji i wymiana wszystkich sekretów. Nie odtwarzaj backupu konfiguracji z przejętego urządzenia.
Liczba, którą warto zapamiętać
122 500 — tyle urządzeń MikroTik miało SSH osiągalne z internetu w dobowym oknie skanowania Shadowserver Foundation 5 września, dwa dni po wydaniu poprawek i trzy dni po pierwszym potwierdzonym ataku. To nie jest liczba urządzeń podatnych — Shadowserver wyraźnie zaznacza, że nie sprawdzał wersji. To liczba urządzeń, na których ktoś świadomie wystawił port zarządzania na zewnątrz i uznał, że hasło wystarczy.
Uwierzytelnianie kluczem SSH przez lata było w tej branży odpowiedzią na wszystko. MikroTrick pokazuje, że mechanizm uwierzytelniania jest wart dokładnie tyle, ile wart jest kod, który go implementuje — a tego kodu nikt z zewnątrz nie audytuje. Dlatego port zarządzania nie powinien być osiągalny z internetu nawet wtedy, gdy uwierzytelnianie wydaje się nie do złamania. Zwłaszcza wtedy.