MikroTik po raz pierwszy w swojej historii wysłał powiadomienie push na telefony ludzi, którzy mają jego aplikację. Powód opisał CERT Polska. To sześć podatności w systemie MikroTik RouterOS, w tym dwie krytyczne. Złączone w jedną drogę pozwalają przejąć pełną kontrolę nad urządzeniem bez logowania. Warunek jest jeden i trzeba go czytać dosłownie: usługa SSH musi być osiągalna z sieci publicznej. Polski zespół nazwał ten łańcuch MikroTrick i potwierdził, że ktoś już z niego korzysta, co najmniej od 2 września.
Rekomendacja Pełnomocnika ds. Cyberbezpieczeństwa z 1 października
Aktualizacja z 3 października 2026: 1 października Pełnomocnik Rządu do Spraw Cyberbezpieczeństwa wydał rekomendację nr 2026/33/5 w sprawie tych samych sześciu luk. Ministerstwo Cyfryzacji opublikowało ją 2 października. Rekomendacja jest skierowana do podmiotów krajowego systemu cyberbezpieczeństwa. Zaleca niezwłoczną aktualizację RouterOS co najmniej do wersji 7.25 beta 3, 7.24.2, 7.23.4 albo 6.49.21. Ponieważ atakujący już wykorzystują luki, zaleca też sprawdzić, czy router nie został przejęty, według instrukcji producenta o znaczniku “Flagged”. Do tego zaleca wyłączenie usług SSH, WWW/WWW-SSL, WinBox i serwera bandwidth-test albo zablokowanie do nich dostępu ze wszystkich adresów spoza zaufanych sieci zarządzających. Konsultacja z CSIRT NASK, CSIRT GOV i CSIRT MON potwierdziła według dokumentu możliwość wystąpienia incydentu krytycznego, jeśli rekomendacja nie zostanie zastosowana. Formalnie rekomendacja dotyczy podmiotów tego systemu, ale wersje z poprawkami są te same, które podaje CERT Polska.
Aktualizacja z 8 października 2026: 6 października MikroTik uzupełnił swój komunikat o wrześniowych lukach o numery wszystkich sześciu CVE i poprawił wersje dla jednej z nich. Poprawka CVE-2026-67278 (podrobione certyfikaty i klucze hosta SSH) w 7.24.2 i 7.23.4 okazała się niepełna. Pełna jest w 7.24.3 (stable) i 7.23.6 (long-term), więc kto zaktualizował we wrześniu do 7.24.2 albo 7.23.4, powinien zaktualizować ponownie. RouterOS 6 tej luki nie ma. Na 8 października najnowsze wydania to 7.24.5 (stable) i 7.23.7 (long-term). Osobna, nowa luka w panelu WWW, CVE-2026-84411, ma poprawkę tylko w kanale stable, co opisujemy w tekście o luce w panelu WWW MikroTika.
Czym jest MikroTrick i dlaczego wystarczyły dwie luki
Pierwsza podatność siedzi w logowaniu kluczem SSH. RouterOS sprawdzał typ klucza i jego moduł, ale nie porównywał całego klucza publicznego RSA przypisanego użytkownikowi. Wykładnik zostawał poza kontrolą. Kto zna nazwę konta i publiczny moduł jego klucza, może podać własny klucz z wykładnikiem równym jeden, podrobić podpis i otworzyć sesję. Klucz prywatny nie jest do niczego potrzebny. Ocena to 9,2 w dziesięciostopniowej skali CVSS.
Druga jest banalna do opisania i dlatego wyjątkowo nieprzyjemna. RouterOS źle obsługiwał nazwy użytkownika zaczynające się od niedozwolonego znaku. Spreparowana nazwa pozwalała podmienić maskę uprawnień, a uzyskana sesja miała pełne prawa administracyjne. Też 9,2.
Osobno każda z nich jest kłopotem. Pierwsza daje dokładnie tyle uprawnień, ile miało zaatakowane konto. Druga wymaga tego, żeby sesja w ogóle dotarła do mechanizmu logowania. Złączone tworzą drogę od anonimowego połączenia do pełnych uprawnień administracyjnych i to jest cała treść nazwy MikroTrick. Warunek pozostaje ten sam: SSH musi być osiągalne z sieci publicznej. CERT nadał tej kombinacji nazwę po to, żeby dało się o niej rozmawiać bez recytowania dwóch numerów.
Sześć podatności, nie dwie. Co jeszcze załatano w RouterOS
Reszta stawki nie trafiła do nagłówków, a dwie pozycje z niej zasługują na osobną chwilę uwagi.
Trzecia opisana szczegółowo luka dotyczy usługi bandwidth-test i ma ocenę 8,8. Nieuwierzytelnione połączenie mogło wejść w stan zarezerwowany dla zalogowanych. W parze z ujawnieniem niezainicjalizowanych danych z bufora pakietów i błędem przy sprawdzaniu rozmiaru dawało to wyciek pamięci jądra albo zdalny restart systemu.
Trzy pozostałe CERT wypisał na osobnej podstronie z opisami wszystkich sześciu numerów, bez ocen liczbowych. Pierwsza z nich dotyczy sprawdzania certyfikatów X.509. Magazyn zaufania RouterOS zawiera korzeń z wykładnikiem trzy. Napastnik kontrolujący wychodzące połączenie TLS mógł dzięki temu podrobić pośredni urząd certyfikacji i wystawić certyfikat na dowolną nazwę. Druga pozwalała uruchomić polecenie bez żadnego uwierzytelnienia, po wymuszonej zmianie kluczy sesji SSH, i nadpisywać pliki na urządzeniu. Trzecia to odczyt plików przez interfejs WebFig, również bez logowania, z dostępem do magazynów konfiguracji zawierających poświadczenia.
Zwróć uwagę, czego ta lista dotyczy. Nie jednego modułu, tylko serwera i klienta SSH, usługi bandwidth-test, obsługi certyfikatów i panelu webowego naraz.
Jak sprawdzić, czy twój MikroTik jest już cudzy
Zacznij od numeru wersji, bo to jedyna rzecz, którą da się rozstrzygnąć w kilkanaście sekund. CERT podaje trzy zakresy wersji podatnych i przypisane im wydania z poprawką.
| Gałąź RouterOS | Wersje podatne | Wersja z poprawką |
|---|---|---|
| 7.24 (Stable) | od 7.24 do wersji poniżej 7.24.2 | 7.24.2 |
| 7.x (Long-term) | od 7.0.0 do wersji poniżej 7.23.4 | 7.23.4 |
| 6.x (Long-term) | od 6.0.0 do wersji poniżej 6.49.21 | 6.49.21 |
Poprawki trafiły też do gałęzi testowej, w wydaniu 7.25beta3. Pełna poprawka CVE-2026-67278 jest w 7.24.3 i 7.23.6.
Zacznij od trzech wskaźników, a potem przejrzyj całą konfigurację. W logu szukaj wpisów login failure for user -2 from <ip> via ssh oraz user <name> added by ssh:-2@<ip>. Sprawdź listę kont: dodatkowym wskaźnikiem jest wysoce uprzywilejowany użytkownik o nazwie ops. Udane ataki i tworzenie tego konta CERT powiązał z adresem 82.192.72.4, co najmniej od 2 września. Z adresu 103.102.31.18 prowadzono próby eksploatacji. W pełnej analizie z 22 września CERT dokłada czwarty ślad z logów opublikowanych na polskim forum trzepak.pl: utworzenie pliku diagnostycznego RIF i wysłanie danych poleceniem fetch na ten sam adres 82.192.72.4. CERT ocenia to jako wyprowadzanie plików diagnostycznych z wysokim prawdopodobieństwem.
Sama lista kont to za mało. CERT zaleca przejrzeć też konfigurację: nieznane skrypty, zadania harmonogramu, serwery proxy i tunele. Do tego wszystko inne, czego nie rozpoznajesz.
W poprawionych wydaniach producent uruchomił mechanizm “Flagged”. Przy starcie systemu skanuje on konfigurację w poszukiwaniu znanych oznak nieautoryzowanych zmian, wyłącza rozpoznane wpisy, zapisuje komunikat krytyczny w logu i ustawia znacznik. Wartość znacznika zobaczysz poleceniem /system/device-mode/print.
Teraz zdanie, którego nie wolno pominąć, bo bez niego cała ta sekcja uspokaja fałszywie. Brak znacznika nie jest dowodem, że urządzenie jest bezpieczne. Mechanizm wykrywa tylko wybrane ślady, a CERT dodaje wprost, że nie może wykluczyć podatności, których producent nie opisał w dzienniku zmian.
Jeśli aktualizacja jest w tej chwili niemożliwa, CERT podaje dwa środki doraźne. Pierwszy: odetnij usługi wystawione na zewnątrz, w szczególności SSH, WWW oraz serwer bandwidth-test, od adresów spoza zaufanej sieci zarządzania. Drugi bywa pomijany w relacjach, a dotyczy ruchu w drugą stronę. Z niezaktualizowanego urządzenia nie inicjuj połączeń TLS. Nie używaj też wbudowanych klientów /system ssh oraz /system ssh-exec, zwłaszcza przez niezaufane sieci albo do niezaufanych hostów. Oba środki są tymczasowe i nie zastępują aktualizacji. Zasady, które porządkują pierwszy z nich, są te same co przy zabezpieczaniu zwykłego serwera po SSH.
Producent uspokaja, CERT ostrzega, a obie strony piszą prawdę
To jest miejsce, w którym łatwo napisać nieprawdę w jedną albo w drugą stronę. Dwa dni przed wpisem CERT-u MikroTik opublikował własny biuletyn. Stwierdza w nim, że “większość konfiguracji nie jest zagrożona”. Dla zwykłych użytkowników domowych problem “nie stanowi bezpośredniego ryzyka”. Dodaje też, że celowo nie publikuje szczegółów, żeby dać ludziom czas na aktualizację.
Polski zespół pisze co innego: obserwuje ataki, ma potwierdzenie pełnego przejmowania urządzeń i zaleca pilną aktualizację. Obie wypowiedzi mogą być prawdziwe naraz, bo dotyczą czego innego. MikroTik informuje, że większość konfiguracji nie jest zagrożona, ale nie opisuje ich rozkładu ani nie podaje żadnych liczb. CERT mówi o konkretnym wycinku, czyli o urządzeniach z SSH dostępnym z sieci publicznej, i w tym wycinku potwierdza pełne przejęcia.
Praktyczny wniosek jest więc prosty. Jeżeli twoje urządzenie należy do tego wycinka, zdanie o braku bezpośredniego ryzyka ciebie nie dotyczy, a aktualizacja i kontrola konfiguracji są pilne. Wcześniejszą publikację CERT tłumaczy zresztą rzeczowo: paczki z poprawką są już publiczne, a porównanie wydań pozwoliło części społeczności odtworzyć załatane błędy. Uznał więc, że administratorzy potrzebują już informacji pozwalających ograniczyć ryzyko. Nie opublikował przy tym kodu ataku ani szczegółów ułatwiających jego automatyzację.
Luki znalazły modele OpenAI, ale to nie jest historia o jednym poleceniu
Advisory kończy się sekcją o tym, jak te luki znaleziono. Podatności odnalazł zespół CERT Polska przy użyciu modeli GPT-5.5-cyber i GPT-5.6-sol, w ramach dostępu do programu OpenAI Government and Trust Agency Collaboration. O samym otwarciu tego kanału dla polskiej instytucji pisaliśmy wcześniej, wtedy jeszcze bez konkretnego wyniku po drugiej stronie.
Jak to wyglądało w praktyce? Badacze zbudowali odizolowane laboratorium z maszynami MikroTika, dokumentacją architektury i regułami bezpiecznego uruchamiania testów. Agent automatyzował tworzenie i przywracanie maszyn, pobieranie i porównywanie wersji, analizę dokumentów RFC oraz kodu binarnego, a także pisanie skryptów potwierdzających istnienie błędu. Najlepiej działało modelowanie protokołów jako maszyn stanów i sprawdzanie, co się dzieje, gdy któryś etap zostanie pominięty, powtórzony albo wykonany w złej kolejności. Ten sposób analizy pasuje do mechanizmu kilku opisanych luk, choćby tej z połączeniem bandwidth-test wchodzącym w stan zarezerwowany dla zalogowanych.
CERT sam gasi przy tym najprostszą wersję tej historii. Pisze wprost, że nie był to efekt jednego polecenia. Każda hipoteza wymagała potwierdzenia na realnym RouterOS, testów kontrolnych, powtórzenia na czystej maszynie i oceny wpływu przez ludzi. Najbardziej pracochłonne okazały się przygotowanie kontekstu o systemie, projekt bezpiecznego laboratorium, wybór kierunków badania i późniejsza weryfikacja wyników razem z odsiewaniem fałszywych wniosków. Modele przyspieszyły analizę i przeszukiwanie hipotez. Nie zastąpiły żadnego z tych etapów. Ten sam zespół publikuje zresztą moduł wiedzy o podatnościach dla administratorów, więc trudno go podejrzewać o wiarę w automat rozwiązujący wszystko za człowieka. Jak wyglądało laboratorium agenta i co CERT mu przypisuje, a czego nie, opisujemy w tekście o pracy agenta AI przy badaniu MikroTika.
Pierwsza Misja AI · Kodożercy
AI zmienia rynek pracy. Zacznij rozumieć o co chodzi.
Kurs Pierwsza Misja AI to najkrótszy kurs, po którym naprawdę rozumiesz AI, a na koniec możesz to pokazać certyfikatem. Fabuła w konwencji science fiction i gamifikacja sprawiają, że nie nudzisz się ani minuty.
Dołącz do kursantów →
Najczęstsze pytania
Mam MikroTika w domu, muszę coś robić?
Zaktualizuj, ale bez nerwów. Producent pisze, że dla zwykłych użytkowników domowych problem nie stanowi bezpośredniego ryzyka. Cały łańcuch wymaga dostępu do SSH z sieci publicznej, a w domowej instalacji ta usługa zwykle nie jest wystawiona na zewnątrz. Warto to jednak sprawdzić, zamiast zakładać. Jeśli kiedykolwiek konfigurowałeś dostęp do routera spoza domu albo przekierowanie portów, zacznij właśnie od tego.
Znalazłem znacznik “Flagged”. Wystarczy zresetować urządzenie?
Nie w tej kolejności. CERT zaleca najpierw odizolować urządzenie od sieci, a dopiero potem zabezpieczyć jego logi i konfigurację, jeszcze przed resetem. Znacznika nie należy kasować, zanim analiza się skończy, a materiał zostanie zabezpieczony. Informację o ataku trzeba zgłosić właściwemu zespołowi CSIRT. Dopiero na końcu przychodzi przywrócenie ustawień fabrycznych i konfiguracja od nowa, z zaufanego źródła. Pełnej kopii konfiguracji z przejętego urządzenia nie wolno odtwarzać bezrefleksyjnie, bo razem z nią wróciłoby to, co dołożył napastnik. Trzeba też zmienić hasła, klucze i pozostałe sekrety.
Podsumowanie
Po stronie kodu sprawę zamykają wersje 7.24.3 (stable), 7.23.6 (long-term) i 6.49.21 albo nowsze. Wrześniowe 7.24.2 i 7.23.4 miały dla jednej z luk poprawkę niepełną. Łańcuch dwóch krytycznych luk, nazwany przez CERT Polska MikroTrick, prowadzi od anonimowego połączenia do pełnych uprawnień administracyjnych, o ile SSH urządzenia jest osiągalne z sieci publicznej. Udane ataki widziano co najmniej od 2 września, czyli dzień przed wydaniem poprawek. Po aktualizacji zaczyna się druga część roboty. Najpierw trzy wskaźniki: wpisy w logu, uprzywilejowane konto ops i wartość znacznika “Flagged”. Potem przegląd całej konfiguracji, w tym nieznanych skryptów, zadań harmonogramu, serwerów proxy i tuneli. Żadna z tych czynności nie daje pewności, że urządzenie jest czyste, bo brak śladów niczego nie dowodzi. Dają za to jedyną rzecz, jaką administrator dostał w tym tygodniu za darmo: konkretną listę do odhaczenia, zamiast ogólnego zalecenia, żeby uważać.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
