Zespół CERT Polska zidentyfikował oraz koordynował ujawnienie sześciu podatności w MikroTik RouterOS. Jeśli urządzenie wspiera zdalny dostęp przy użyciu protokołu SSH, to wykorzystanie dwóch z tych podatności umożliwia przejęcie pełnej kontroli nad urządzeniem bez uwierzytelniania. Nadaliśmy tej kombinacji podatności nazwę MikroTrick w celu ułatwienia jej identyfikacji.

W ostatnich dniach obserwujemy ataki na RouterOS dostępne z internetu. Uzyskaliśmy potwierdzenie, że atakujący wykorzystują tę kombinację podatności do przejęcia pełnej kontroli nad urządzeniami, których usługa SSH jest dostępna z publicznych sieci. Potwierdzono również, że wydane poprawki uniemożliwiają przeprowadzanie obserwowanych ataków. Zalecamy pilne wykonanie aktualizacji.

Opisane przez nas podatności obejmują serwer i klienta SSH, usługę bandwidth-test, obsługę certyfikatów X.509 oraz interfejs WebFig. MikroTik udostępnił poprawki w wydaniach 7.25beta3, 7.24.2, 7.23.4 oraz 6.49.21, o czym informuje w swoim biuletynie bezpieczeństwa. Wraz z tą aktualizacją MikroTik po raz pierwszy w historii wysłał powiadomienie push na telefony użytkowników, którzy mieli zainstalowaną aplikację MikroTik. Administratorzy powinni zaktualizować urządzenia możliwie szybko, a następnie sprawdzić konfigurację pod kątem nieznanych użytkowników, skryptów, zadań harmonogramu, serwerów proxy i tuneli.

Zidentyfikowane podatności

W ramach badań zidentyfikowaliśmy sześć podatności w RouterOS, poniżej opisujemy szczegóły trzech najważniejszych, a wszystkie można znaleźć na dedykowanej podstronie.

CVE-2026-67276 - obejście uwierzytelnienia SSH (CVSS: 9.2)

RouterOS nieprawidłowo weryfikował klucze publiczne używane do uwierzytelniania SSH - w szczególności nie porównywał całego klucza publicznego RSA przypisanego użytkownikowi. Atakujący znający nazwę użytkownika oraz publiczny moduł jego klucza mógł przygotować inny klucz i zalogować się przez SSH bez posiadania odpowiadającego mu klucza prywatnego. Uzyskane uprawnienia odpowiadały uprawnieniom zaatakowanego konta.

CVE-2026-86060 - manipulacja uprawnieniami sesji SSH za pomocą spreparowanej nazwy użytkownika (CVSS: 9.2)

RouterOS nieprawidłowo obsługiwał nazwy użytkowników rozpoczynające się od niedozwolonego znaku w mechanizmie logowania SSH. Atakujący mógł użyć spreparowanej nazwy użytkownika do eskalacji uprawnień. Uzyskana sesja miała pełne uprawnienia administracyjne w systemie RouterOS.

CVE-2026-67277 - ujawnienie pamięci i awaria przez bandwidth-test (CVSS: 8.8)

Usługa bandwidth-test pozwalała nieuwierzytelnionemu połączeniu wejść w stan, który powinien być dostępny dopiero po zalogowaniu. W połączeniu z dwoma odrębnymi błędami - ujawnieniem niezainicjalizowanych danych z bufora pakietów oraz błędem typu integer underflow przy walidacji rozmiaru - umożliwiało to wyciek pamięci jądra albo zdalny atak DoS prowadzący do restartu systemu.

Obserwowane ataki na RouterOS i mechanizm „Flagged”

Poszlaki techniczne oraz informacje pozyskane przez CERT Polska kanałami wewnętrznymi wskazywały na możliwość aktywnego wykorzystywania podatności RouterOS w rzeczywistych atakach prowadzonych w ostatnich dniach. Obecnie posiadamy już potwierdzenie, że połączenie dwóch podatności (MikroTrick) jest wykorzystywane do przejęcia pełnej kontroli nad urządzeniami, których usługa SSH jest dostępna z publicznych sieci. Według posiadanych informacji aktualizacja do najnowszej wersji uniemożliwia przeprowadzenie tych ataków.

W poprawionych wydaniach MikroTik wykorzystał mechanizm, który podczas uruchamiania RouterOS analizuje konfigurację w poszukiwaniu znanych oznak nieautoryzowanych zmian, wyłącza rozpoznane podejrzane wpisy konfiguracyjne, zapisuje komunikat krytyczny w logu i ustawia ostrzeżenie (znacznik „Flagged”). Mechanizm ten wykrywa jedynie wybrane ślady pozostawione po kompromitacji - brak flagi nie jest dowodem, że urządzenie jest bezpieczne. Szczegóły postępowania producent opisuje w dokumentacji mechanizmu „Flagged”.

Nie możemy wykluczyć występowania nieznanych nam podatności, których producent nie opisał w changelogu. Mechanizm oznaczania skompromitowanych urządzeń „Flagged” należy zatem traktować jako informację o możliwej wcześniejszej kompromitacji, a nie jako dowód wykorzystania jednej z podatności zgłoszonych przez CERT Polska.

Jeżeli urządzenie zostało oznaczone jako skompromitowane, należy przeprowadzić działania opisane w sekcji Rekomendacje.

Obserwowane ataki pozostawiały po sobie następujące znaczniki w dzienniku RouterOS:

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

Dodatkowym wskaźnikiem kompromitacji jest obecność wysoce uprzywilejowanego użytkownika o nazwie „ops”.

W zakresie aktywnego wykorzystania podatności CERT Polska podczas analizy ustalił, że obserwowane do tej pory udane ataki oraz tworzenie konta "ops" były prowadzone z adresu ip 82.192.72.4, co najmniej od 02.09. Dodatkowo adres IP 103.102.31.18 prowadził próby ekspploitacji opisanej podatnośći.

Obecność dowolnego z tych artefaktów oznacza próbę wykorzystania podatności i musi zostać niezwłocznie zbadana, jednocześnie brak wspomnianych śladów nie wyklucza nieautoryzowanych działań.

Rekomendacje

Rekomendujemy niezwłoczną aktualizację RouterOS do jednej z wersji zawierających poprawki: 7.25beta3, 7.24.2, 7.23.4 albo 6.49.21. Po aktualizacji należy sprawdzić logi pod kątem komunikatu o kompromitacji urządzenia oraz wartość znacznika flagged w wyniku polecenia /system/device-mode/print. Należy także zweryfikować konfigurację w poszukiwaniu nieznanych użytkowników, skryptów i innych nierozpoznanych zmian. Kontrolę oraz dalsze postępowanie należy przeprowadzić zgodnie z biuletynem bezpieczeństwa MikroTik i wskazaną w nim dokumentacją znacznika „Flagged”. Brak znacznika nie wyklucza wcześniejszej kompromitacji.

Jeżeli natychmiastowe zainstalowanie poprawki nie jest możliwe, do czasu aktualizacji należy:

• Wyłączyć narażone usługi albo zablokować dostęp do nich ze wszystkich adresów spoza zaufanych sieci zarządzających. Dotyczy to w szczególności SSH, WWW/WWW-SSL oraz serwera bandwidth-test;
• Nie inicjować z niezaktualizowanego urządzenia połączeń TLS ani nie korzystać z wbudowanych klientów SSH (/system ssh i /system ssh-exec), w szczególności gdy komunikacja przebiega przez niezaufane sieci lub jest kierowana do niezaufanych hostów.

Są to wyłącznie środki tymczasowe, ograniczające powierzchnię ataku. Nie zastępują one instalacji poprawionej wersji RouterOS.

Jeżeli znacznik „Flagged”, logi, konfiguracja albo inne okoliczności wskazują na możliwą kompromitację, urządzenie należy odizolować od sieci i przed wykonaniem resetu zabezpieczyć jego logi oraz konfigurację. Instrukcję pozyskania tych danych opisuje artykuł CERT Polska „MikroTik - zabezpieczanie logów i konfiguracji”. Należy zgłosić do właściwego zespołu CSIRT informację o zaobserwowanym ataku wg instrukcji.

Po zabezpieczeniu materiału urządzenie należy przywrócić do ustawień fabrycznych, skonfigurować ponownie na podstawie zaufanej i zweryfikowanej konfiguracji oraz zmienić używane hasła, klucze i inne sekrety. Nie należy bezrefleksyjnie odtwarzać pełnej kopii konfiguracji pochodzącej z potencjalnie przejętego urządzenia. Znacznika „Flagged” nie należy kasować przed zakończeniem analizy i zabezpieczeniem materiału.

Badanie wspierane przez modele LLM

Podatności zostały odnalezione przez 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 GTAC.

Modele wykorzystano jako element agentowego środowiska badawczego do automatyzacji laboratorium oraz systematycznego wyszukiwania podatności w obszarach wybranych i nadzorowanych przez badaczy.

Zespół przygotował izolowane laboratorium z maszynami MikroTik, dokumentację jego architektury systemu oraz zasady bezpiecznego wykonywania testów. Agent automatyzował tworzenie i przywracanie maszyn, pobieranie oraz porównywanie wersji, analizę RFC i kodu binarnego, a także budowę skryptów potwierdzających występowanie podatności. Szczególnie skuteczne okazało się modelowanie protokołów jako maszyn stanów i sprawdzanie, co nastąpi po pominięciu, powtórzeniu albo wykonaniu etapu w niewłaściwej kolejności.

Nie był to jednak rezultat pojedynczej instrukcji (promptu). Każda hipoteza wymagała potwierdzenia na rzeczywistym RouterOS, negatywnych testów kontrolnych, powtórzenia na czystym stanie maszyny oraz oceny wpływu przez badaczy. Mimo dużego stopnia automatyzacji najbardziej pracochłonną częścią projektu pozostało przygotowanie użytecznego kontekstu o RouterOS, zaprojektowanie bezpiecznego laboratorium i narzędzi, wybór kierunków badań, a następnie pełna weryfikacja wyników, eliminowanie fałszywych wniosków oraz udokumentowanie rzeczywistego wpływu każdej podatności. Modele znacząco przyspieszyły analizę i eksplorację hipotez, ale nie zastąpiły tych etapów.

Dlaczego publikujemy teraz

Informację publikujemy w przyspieszonym trybie, ponieważ poprawione pakiety RouterOS są już publiczne, a ich analiza porównawcza pozwoliła społeczności odtworzyć część usuniętych błędów. Ograniczamy opis do informacji potrzebnych administratorom i nie publikujemy kodu exploitów ani szczegółów ułatwiających automatyzację ataków.

Najważniejszym zaleceniem pozostaje natychmiastowa aktualizacja RouterOS oraz weryfikacja, czy urządzenie nie zawiera nieznanych kont, skryptów i zmian konfiguracji.