A CERT Polska kutatói hat sebezhetőséget találtak a MikroTik RouterOS-ben, amelyek az SSH szervert és klienst, a bandwidth-test szolgáltatást, az X.509 tanúsítványkezelést és a WebFig felületet érintik. A három legkritikusabb közül kettő kombinálva teljes, hitelesítés nélküli hozzáférést ad az eszközhöz, ha az SSH szolgáltatás nyilvánosan elérhető.
A CERT Polska megerősítette, hogy a támadók már ki is használják ezt a hibapárt olyan eszközök ellen, amelyeknek SSH-szolgáltatása nyilvánosan elérhető, és azt is, hogy a kiadott javítások megállítják a megfigyelt támadásokat. A sikeres támadások legalább szeptember 2. óta zajlanak, és a 82[.]192.72.4 IP címről indultak, míg a 103[.]102.31.18 cím kísérleti próbálkozásokban jelent meg.
CVE-2026-67276 (CVSS 9.2): SSH-hitelesítés megkerülése. A RouterOS nem ellenőrizte megfelelően a nyilvános kulcsokat, csak részlegesen hasonlította össze a teljes RSA-kulcsot. Ha egy támadó ismerte a felhasználónevet és a kulcs nyilvános modulusát, más kulcsot is elfogadtatott a rendszerrel, és bejelentkezhetett a magánkulcs birtoklása nélkül, a célzott fiók jogosultságaival.
CVE-2026-86060 (CVSS 9.2): jogosultság kiterjesztés preparált felhasználónévvel. A rendszer hibásan kezelte a tiltott karakterrel kezdődő felhasználóneveket az SSH bejelentkezésnél, így egy megfelelően összeállított névvel a támadó teljes rendszergazdai jogosultságú sessiont szerezhetett.
CVE-2026-67277 (CVSS 8.8): memóriakiszivárgás és összeomlás a bandwidth-test szolgáltatáson keresztül. Egy hitelesítés nélküli kapcsolat elérhetett egy olyan állapotot, amelyhez normálisan bejelentkezés kellene; ez inicializálatlan memóriaterület kiszivárgásához (kernel memory leak) vagy távoli szolgáltatásmegtagadáshoz (újraindulás) vezethet.
Ezek együtt teszik ki a “MikroTrick” néven elnevezett támadási láncot: az első két hiba kombinációja hitelesítés nélküli teljes eszközátvételt tesz lehetővé.
A MikroTik a javított kiadásokban egy “Flagged” mechanizmust is bevezetett, amely indításkor átvizsgálja a konfigurációt ismert kompromittálódási jelek után, letiltja a felismert gyanús bejegyzéseket, kritikus üzenetet ír a logba, és beállít egy figyelmeztető jelzőt. Fontos azonban, hogy ez csak bizonyos ismert nyomokat észlel, a jelző hiánya nem garancia arra, hogy az eszköz biztonságos.
A MikroTik a következő verziókban adta ki a javításokat: 7.25beta3, 7.24.2, 7.23.4 és 6.49.21. Ezzel egy időben, a cég történetében először push értesítést küldött a MikroTik appot használó felhasználók telefonjaira.
Az azonnali frissítés a legfontosabb lépés, de ha ez nem lehetséges rögtön, a CERT Polska ideiglenes intézkedésként a következőket ajánlja:
- Az internet felől ne legyen elérhető az SSH, a WWW/WWW-SSL felület és a bandwidth-test szerver, korlátozzuk a hozzáférést csak megbízható menedzsment-hálózatokra.
- Ne indítunk TLS kapcsolatot egy nem javított eszközről, és ne használjuk a beépített SSH-klienst (/system ssh, /system ssh-exec), különösen ha a kommunikáció megbízhatatlan hálózaton vagy megbízhatatlan célponton keresztül zajlik.
Ezek csak ideiglenes, kockázatcsökkentő lépések, nem helyettesítik a frissítést.
Frissítés után ellenőrizzük a logokat kompromittálódásra utaló üzenetek után, és nézzük meg a “flagged” jelző értékét az /system/device-mode/print parancs kimenetében. Vizsgáljuk át a konfigurációt ismeretlen felhasználók, scriptek, ütemezett feladatok (scheduler), proxy szerverek és tunnelek után is.
A sebezhetőségeket a CERT Polska csapata az OpenAI Government and Trust Agency Collaboration (GTAC) program keretében, GPT-5.5-cyber és GPT-5.6-sol modellek segítségével fedezte fel. A modelleket egy ágens-alapú kutatási környezetben használták, amely automatizálta a laborépítést, a verziók összehasonlítását, a bináris kód és RFC-k elemzését, valamint a sebezhetőségeket igazoló scriptek megírását. Különösen hatékonynak bizonyult a protokollok állapotgépkénti modellezése és annak vizsgálata, mi történik, ha egy lépést kihagynak, megismételnek vagy rossz sorrendben végeznek el. A csapat hangsúlyozza, hogy ez nem egyetlen promptból született eredmény volt. Minden hipotézist valós RouterOS rendszeren kellett megerősíteni, negatív kontrollteszttel és tiszta állapotú gépen való megismétléssel, majd a kutatók hatásvizsgálatával.