MikroTik RouterOS sérülékenység 2026: frissítés és audit éles környezetben

English version: Read this article in English

2026 szeptemberének elején a MikroTik fontos biztonsági frissítést adott ki a RouterOS rendszerhez. A gyártó a sérülékenység részletes technikai hátterét egyelőre szándékosan nem hozta nyilvánosságra, hogy az üzemeltetőknek legyen idejük frissíteni az eszközeiket, mielőtt a hiba pontos működése szélesebb körben ismertté válik. [1]

Ez nem egy olyan RouterOS-frissítés, amelyet érdemes egyszerűen a következő általános karbantartási ablakra hagyni.

Egy éles üzemeltetési környezetben ezért több, eltérő generációjú MikroTik routeren is elvégeztük a frissítést és az azt követő biztonsági ellenőrzést.

A környezetben modern és régebbi RouterBOARD eszközök, WireGuard VPN-kapcsolatok, több internetkapcsolatot kezelő konfigurációk, publikus IP-címekkel működő routerek, SNMP-monitoring és kis flash tárhellyel rendelkező eszközök egyaránt előfordultak.

A gyakorlati tapasztalat azt mutatta, hogy ennél a biztonsági eseménynél nem elég pusztán a RouterOS verziószámát megváltoztatni.

A frissítés után érdemes ellenőrizni:

• a RouterOS verzióját,
• a RouterBOARD firmware-t,
• a Device Mode `flagged` állapotát,
• a felhasználókat,
• a RouterOS scripteket,
• a schedulert,
• a Netwatch konfigurációt,
• az aktív management szolgáltatásokat,
• és a WAN felőli input firewall működését.

Mit jelentett be a MikroTik 2026 szeptemberében?

A MikroTik 2026. szeptember 3-án jelentette be, hogy biztonsági sérülékenységet talált a RouterOS rendszerben, és a javítást tartalmazó kiadások minden támogatott frissítési csatornához megjelentek. [1]

A gyártó hivatalos közleménye szerint a legtöbb konfiguráció nincs közvetlen veszélyben, ugyanakkor a frissítés erősen ajánlott.

A MikroTik egyelőre nem publikálta a sérülékenység részletes technikai leírását.

Ennek hivatalos oka az, hogy időt kívánnak biztosítani a felhasználóknak és üzemeltetőknek a rendszerek frissítésére.

A közlemény egy másik fontos részlete, hogy a frissített RouterOS ellenőrzi az eszközt kompromittálásra utaló jelek után.

Ha ilyen jelet talál, a router Flagged állapotba kerülhet, és erről kritikus logbejegyzés készül. [1]

Mely RouterOS-verziók tartalmazzák a javítást?

A MikroTik hivatalos biztonsági közleménye szerint a javítás az alábbi verzióktól található meg: [1]

• RouterOS 7 development: 7.25 beta 3
• RouterOS 7 stable: 7.24.2
• RouterOS 7 long-term: 7.23.4
• RouterOS 6: 6.49.21

A long-term ág esetében azonban van egy fontos részlet.

A 7.23.4 2026. szeptember 3-án jelent meg, és már tartalmazta a biztonsági javítást.

Egy nappal később, szeptember 4-én azonban megjelent a 7.23.5 long-term verzió is.

A MikroTik közlése szerint erre azért volt szükség, mert a 7.23.4-ben sürgős IPv6 DHCP regresszió jelent meg. A 7.23.5 ezt a problémát javította. [2]

Ezért aki jelenleg long-term ágon frissít, annak már 7.23.5-re célszerű frissítenie, nem pedig megállnia a 7.23.4-nél.

Megjelent az első független technikai elemzés is

A MikroTik hivatalosan továbbra sem tette közzé a sérülékenység teljes technikai leírását, de a javított RouterOS binárisok természetesen elérhetők.

Ez lehetővé tette, hogy független biztonsági kutatók reverse engineering módszerekkel összehasonlítsák a javítás előtti és utáni RouterOS-verziókat.

2026. szeptember 4-én Nick Pratley részletes technikai elemzést publikált a RouterOS 7.23.3 és 7.23.4 közötti változásokról. [3]

A kutató a javított komponenseket és bináris változásokat vizsgálva több, biztonsági szempontból érdekes módosítást azonosított.

Kiemelt figyelmet kapott az SSH belső működésének átalakítása és egy TFTP-hez kapcsolódó komponens módosítása.

A RouterOS 7.23.4 hivatalos changelogjában valóban szerepel többek között:

• az SSH belső folyamatainak átdolgozása,
• a TFTP kliens stabilitásának javítása,
• valamint több rendszerkomponens stabilitási módosítása. [4]

A független kutatás ezek alapján egy lehetséges támadási láncot is részletesen vizsgál.

Fontos azonban, hogy ez független reverse-engineering elemzés, nem a MikroTik hivatalos sérülékenységi dokumentációja.

Ezért a külső kutatási eredményeket érdemes komolyan venni, de világosan el kell választani attól, amit maga a gyártó már hivatalosan megerősített.

A technikai kép még változhat

A biztonsági frissítés megjelenése óta a MikroTik közösségi fórumán is aktív szakmai vita alakult ki a sérülékenység pontos működéséről. [5]

A jelenlegi külső kutatások már jóval több technikai információt tartalmaznak, mint a gyártó rövid közleménye.

Ugyanakkor egy ilyen gyorsan fejlődő biztonsági eseménynél fontos különválasztani:

1. Amit a MikroTik hivatalosan megerősített.

2. Amit független kutatók reprodukáltak.

3. Amit jelenleg még csak feltételeznek vagy vizsgálnak.

A biztos üzemeltetési következtetés ettől nem változik:

a javított RouterOS-verziót telepíteni kell.

Frissítés előtt mindig készüljön mentés

Éles hálózati eszközön biztonsági frissítést is csak megfelelő mentés után célszerű elvégezni.

A RouterOS konfigurációról készíthetünk olvasható exportot:

/export file=before-security-update

és bináris rendszermentést:

/system backup save name=before-security-update

A két mentési forma nem ugyanazt a célt szolgálja.

Az export olvasható RouterOS konfigurációt készít.

Ebből később könnyen átnézhetők többek között:

• az interfészek,
• az IP-címek,
• a route-ok,
• a firewall szabályok,
• a VPN-beállítások,
• a service-ek,
• és a scriptek.

A binary backup elsősorban gyors helyreállításnál használható.

Kritikus router esetében a mentést természetesen nem célszerű kizárólag magán az eszközön tárolni.

A MikroTik a frissítés előtt szintén javasolja a backup vagy export elkészítését, a megfelelő szabad tárhely ellenőrzését és annak biztosítását, hogy az eszköz frissítés közben ne veszítse el a tápellátását. [4]

A kis flash tárhellyel rendelkező routerek külön figyelmet igényelnek

A régebbi MikroTik eszközök között ma is sok olyan router működik, amely mindössze 16 MB flash tárhellyel rendelkezik.

Ezeknél a frissítés előtt különösen fontos megnézni:

/system resource print

a telepített csomagokat:

/system package print

és a helyben tárolt fájlokat:

/file print

Egy modern, nagyobb tárhellyel rendelkező RouterBOARD esetében néhány megabájt általában nem jelent problémát.

Egy 16 MB-os eszköznél azonban régi backupok, exportok vagy további csomagok mellett már nagyon szűk lehet a rendelkezésre álló hely.

Kis flash tárhellyel rendelkező MikroTik routeren nem érdemes vakon elindítani a frissítést.

Előbb ellenőrizzük, hogy a szükséges csomagok biztonságosan letölthetők és telepíthetők-e.

A frissítési csatorna és az elérhető verzió ellenőrzése

A frissítési csatorna és a legújabb elérhető verzió ellenőrizhető:

/system package update check-for-updates

A kimenet például ilyen adatokat tartalmaz:

channel: long-term
installed-version: 7.x.x
latest-version: 7.23.5
status: New version is available

Biztonsági frissítésnél célszerű manuálisan lefuttatni a `check-for-updates` parancsot, és nem kizárólag egy korábban lekért vagy cache-elt állapotra hagyatkozni.

A RouterOS frissítése

A mentés és az ellenőrzések után a frissítés elindítható:

/system package update install

A RouterOS letölti a szükséges csomagokat, majd újraindítja a routert.

SSH-kapcsolat esetén ezért teljesen normális, hogy a kapcsolat a reboot során megszakad.

Az újraindulás után elsőként a tényleges verziót érdemes ellenőrizni:

/system resource print

Long-term csatornán a cikk készítésekor az aktuális javított verzió:

version: 7.23.5 (long-term)

A Flagged állapot ellenőrzése

A mostani biztonsági eseménynél ez az egyik legfontosabb utólagos ellenőrzés.

A MikroTik hivatalosan közölte, hogy a frissített RouterOS ellenőrzi az eszközt kompromittálásra utaló jelek után. [1]

Az állapot lekérdezhető:

/system device-mode print

A kívánt eredmény:

flagged: no

Ez jó jel.

A `flagged: no` ugyanakkor nem bizonyítja önmagában, hogy egy teljes biztonsági audit felesleges.

A MikroTik kifejezetten azt javasolja, hogy a nem Flagged eszközök konfigurációját is ellenőrizzük ismeretlen scriptek, felhasználók és más, fel nem ismert beállítások után. [1]

Mit jelent a flagged=yes?

A MikroTik Device Mode dokumentációja szerint a RouterOS induláskor képes a konfigurációt és a rendszer állapotát gyanús módosítások után vizsgálni. [6]

Ha a rendszer ilyen jelet talál:

flagged: yes

állapot jelenhet meg.

A MikroTik dokumentációja ebben az esetben egyértelmű:

az eszközt kompromittáltnak kell feltételezni, és teljes auditot kell végrehajtani.

Nem az a helyes első reakció, hogy egyszerűen kikapcsoljuk a Flagged állapotot.

Előbb meg kell vizsgálni:

• a felhasználókat,
• a scripteket,
• a schedulert,
• a Netwatch bejegyzéseket,
• az aktív szolgáltatásokat,
• a firewallt,
• a VPN-beállításokat,
• és minden olyan konfigurációs elemet, amelynek eredete nem ismert.

A MikroTik a teljes audit után a rendszerjelszavak módosítását és a legfrissebb RouterOS használatát is javasolja. [6]

A felhasználók ellenőrzése

Az egyik legegyszerűbb vizsgálat:

/user print

Azt keressük, van-e:

• ismeretlen felhasználó,
• váratlan full jogosultságú account,
• olyan user, amelynek létrehozására nincs magyarázat.

Egy ismeretlen adminisztrátori fiók természetesen komoly figyelmeztető jel.

RouterOS scriptek ellenőrzése

/system script print detail

Itt nem az a kérdés, hogy található-e script a routeren.

Sok teljesen legitim konfiguráció használ RouterOS scripteket.

A fontos kérdés:

minden scriptet felismerünk-e, és tudjuk-e, milyen funkciót lát el?

Az ismeretlen vagy váratlan script további vizsgálatot igényel.

Scheduler ellenőrzése

/system scheduler print detail

A scheduler időzítetten képes RouterOS-parancsokat és scripteket futtatni.

Ezért egy biztonsági audit során ezt is át kell nézni.

Netwatch ellenőrzése

/tool netwatch print detail

A Netwatch eseményekhez kötve szintén képes parancsokat futtatni.

Ez teljesen legitim hálózatüzemeltetési eszköz, de biztonsági ellenőrzésnél érdemes meggyőződni arról, hogy minden bejegyzése ismert.

A logok átvizsgálása

Egy gyors ellenőrzéshez használható:

/log print where topics~"critical|error|warning|account|system"

Érdemes figyelni többek között:

• váratlan adminisztrátori bejelentkezésekre,
• ismeretlen forrásból érkező management kapcsolatokra,
• új felhasználók létrehozására,
• konfigurációmódosításokra,
• kritikus rendszerüzenetekre,
• és Flagged állapotra utaló bejegyzésekre.

Fontos ugyanakkor, hogy minden `critical` logbejegyzés nem jelent automatikusan kompromittálást.

Például újraindítás után az időszinkronizációhoz kapcsolódó rendszeridő-változás is megjelenhet kritikus témájú logként.

A logot ezért mindig a konkrét esemény tartalma alapján kell értelmezni.

Az aktív szolgáltatásokat is érdemes átnézni

Az egyik leghasznosabb parancs:

/ip service print

Ebből gyorsan látható többek között:

• SSH,
• Telnet,
• FTP,
• HTTP,
• HTTPS,
• WinBox,
• API,
• API-SSL,
• reverse-proxy.

Az alapelv egyszerű:

amire nincs szükség, az lehetőleg ne fusson.

FTP, Telnet, HTTP, API vagy más management szolgáltatás engedélyezése csak akkor indokolt, ha ténylegesen szükség van rá.

Egy aktív szolgáltatást ne kapcsoljunk ki vakon

Az audit során előfordulhat, hogy találunk olyan szolgáltatást, amelyről nem tudjuk azonnal, hogy használatban van-e.

Ilyen lehet például a RouterOS reverse-proxy.

Ahelyett, hogy azonnal letiltanánk, először ellenőrizhető a konfiguráció:

/ip reverse-proxy print detail

majd maga a service:

/ip service print detail where name="reverse-proxy"

és szükség esetén az aktuális kapcsolatok is.

Ha nincs konfigurált reverse-proxy szabály vagy backend, és más vizsgálat sem mutat tényleges használatot, akkor a fölösleges szolgáltatás kikapcsolható.

A fontosabb tanulság:

ne kapcsoljunk ki hálózati szolgáltatást pusztán azért, mert nem emlékszünk, mire való. Előbb bizonyítsuk, hogy nincs használatban.

SSH és WinBox hozzáférésének korlátozása

Ha SSH-ra vagy WinBoxra szükség van, érdemes megfontolni, hogy csak:

• management VPN-ről,
• külön adminisztrációs hálózatról,
• vagy meghatározott belső hálózatokról

legyenek elérhetők.

A management szolgáltatások publikus internet felőli elérhetősége általában kerülendő, ha nincs rá kifejezett üzleti vagy technikai szükség.

Az `/ip service` címkorlátozása ugyanakkor csak egy védelmi réteg.

Nem helyettesíti a megfelelő input firewallt.

A WAN firewall működését is ellenőrizni kell

Egy konfigurációban attól még, hogy létezik egy helyesnek tűnő DROP szabály, érdemes ellenőrizni azt is, hogy valóban arra az interfészre vonatkozik-e, amelyre gondolunk.

A bridge-tagság például lekérdezhető:

/interface bridge port print detail

Az input firewall pedig:

/ip firewall filter print detail where chain=input

Különösen hasznos a szabályszámlálók ellenőrzése:

/ip firewall filter print stats detail where chain=input

Ha egy WAN DROP szabály számlálója növekszik, az gyakorlati bizonyíték arra, hogy a szabály ténylegesen forgalmat kap és csomagokat dob el.

Ez gyakran többet mond, mint önmagában a konfiguráció megléte.

A működő speciális konfigurációt ne építsük át feleslegesen

Biztonsági audit közben könnyű beleesni abba a hibába, hogy minden szokatlan beállítást azonnal át akarunk alakítani.

Egy Dual WAN, több publikus címet kezelő vagy speciális routingot használó routeren azonban ez komoly szolgáltatáskiesést okozhat.

Ha egy konfiguráció működik és az eredete ismert, először read-only ellenőrzésekkel célszerű meggyőződni arról, hogy a tűzfal és a routing a kívánt módon működik.

A biztonsági audit célja nem az, hogy egy működő hálózatot szükségtelenül újratervezzünk.

A RouterBOARD firmware külön frissítendő

A RouterOS frissítésével még nem feltétlenül fejeződik be a karbantartás.

A RouterBOARD eszközök külön RouterBOOT firmware-t használnak. [7]

Az állapot ellenőrizhető:

/system routerboard print

Ha például:

current-firmware: régebbi-verzió
upgrade-firmware: 7.23.5

látható, akkor a RouterOS friss, de a RouterBOOT még nem.

A firmware frissítése:

/system routerboard upgrade

majd:

/system reboot

Újraindulás után ismét:

/system routerboard print

A kívánt állapot, hogy:

current-firmware: 7.23.5
upgrade-firmware: 7.23.5

A MikroTik dokumentációja szerint a RouterOS csomag az új RouterBOOT firmware-t is tartalmazhatja, de azt külön kell alkalmazni. A gyártó javasolja a RouterBOOT naprakészen tartását. [7]

Mit tapasztaltunk éles frissítések során?

A frissítést több, eltérő generációjú és eltérő feladatot ellátó MikroTik routeren hajtottuk végre.

Volt közöttük:

• modern, nagyobb erőforrású RouterBOARD,
• régebbi, 16 MB flash tárhelyű eszköz,
• VPN-t kezelő router,
• több internetkapcsolattal működő konfiguráció,
• és publikus IP-címeket kezelő eszköz is.

A javított long-term RouterOS telepítése minden vizsgált esetben sikeresen végrehajtható volt.

A frissítés utáni ellenőrzések során nem találtunk kompromittálásra utaló jelet.

Az audit ugyanakkor több olyan általános hardening lehetőségre rámutatott, amely közvetlenül nem feltétlenül kapcsolódott a szeptemberi sérülékenységhez, de csökkentette a fölösleges támadási felületet.

Mit érdemes ellenőrizni saját MikroTik routeren?

Egy éles RouterOS-frissítés után legalább az alábbiakat érdemes végignézni:

• RouterOS verzió,
• RouterBOARD firmware,
• Device Mode `flagged` állapot,
• felhasználói fiókok,
• RouterOS scriptek,
• scheduler,
• Netwatch,
• aktív IP service-ek,
• SSH és WinBox hozzáférési korlátozásai,
• input firewall,
• WAN DROP szabályok,
• kritikus firewall szabályok számlálói,
• valamint kis tárhelyű eszközökön a rendelkezésre álló szabad hely.

Ez természetesen nem teljes incidensvizsgálati módszertan, de jó kiindulópont a mostani RouterOS biztonsági frissítés után.

Frissíteni akkor is kell, ha a management nincs kint az interneten?

A jelenlegi információk alapján nem javasolt azt a következtetést levonni, hogy egy adott konfiguráció miatt a frissítés elhagyható.

A MikroTik hivatalos közleménye azt mondja, hogy a legtöbb konfiguráció nincs közvetlen veszélyben, de minden felhasználónak erősen ajánlja a frissítést. [1]

A független kutatások közben már több javított komponens technikai változásait vizsgálják. [3]

Amíg a MikroTik nem publikálja a végleges hivatalos technikai részleteket, nem célszerű kizárólag egyetlen feltételezett támadási felület alapján eldönteni, hogy egy router érintett-e.

A javított RouterOS-verzió telepítése a helyes üzemeltetési döntés.

Miért fontos különválasztani a biztos tényt és a kutatói eredményt?

Gyorsan fejlődő biztonsági eseményeknél könnyen összemosódhat három külön információtípus.

A gyártó által hivatalosan megerősített tény.

A független kutató által reprodukált eredmény.

A még vizsgálat alatt álló feltételezés.

A MikroTik hivatalosan megerősítette:

• a sérülékenység létezését,
• a javított verziókat,
• a frissítés fontosságát,
• és a frissítés utáni Flagged ellenőrzést. [1]

Független kutató ennél részletesebb technikai elemzést publikált a patchek reverse engineering vizsgálata alapján. [3]

A technikai vita jelenleg is folyamatban van.

Ezért ebben a cikkben nem állítunk többet annál, mint amit az adott forrás ténylegesen alátámaszt.

Összegzés

A 2026. szeptemberi MikroTik RouterOS sérülékenységet nem érdemes pánikként kezelni, de nem is szabad egyszerű minor update-ként félretenni.

A MikroTik fontos biztonsági frissítésként kezeli az esetet, és a frissítést erősen ajánlja. [1]

Long-term RouterOS használata esetén a cikk készítésekor a 7.23.5 a megfelelő aktuális verzió. A 7.23.4 már tartalmazza a biztonsági javítást, de az azt követő 7.23.5 egy sürgős IPv6 DHCP regressziót is korrigál. [2]

A RouterOS frissítése után érdemes:

Flagged állapotot ellenőrizni, konfigurációauditot végezni, átnézni a management szolgáltatásokat, ellenőrizni a WAN firewallt és frissíteni a RouterBOARD firmware-t is.

A biztonsági frissítés egyben jó alkalom annak átgondolására is, hogy valóban szükség van-e minden olyan szolgáltatásra, amely az évek során engedélyezve maradt a routeren.

Egy internetkapcsolat határán működő eszköz esetében továbbra is érvényes az egyik legegyszerűbb biztonsági alapelv:

a legkisebb támadási felület az a szolgáltatás, amelyre nincs szükség, ezért nincs bekapcsolva.

Források

[1] MikroTik – September 2026 vulnerability https://mikrotik.com/supportsec/september-2026-vulnerability/

[2] MikroTik – RouterOS 7.23.5 long-term changelog https://forum.mikrotik.com/t/7-23-5-long-term-is-released/272867

[3] Nick Pratley – Reversing MikroTik's Silent Patch: The RouterOS 7.23.4 Fix They Wouldn't Explain https://npratley.net/reversing-mikrotiks-silent-patch-the-routeros-7-23-4-fix-they-wouldnt-explain/

[4] MikroTik Community Forum – RouterOS 7.23.4 long-term release https://forum.mikrotik.com/t/7-23-4-long-term-is-released/272801

[5] MikroTik Community Forum – Important security update https://forum.mikrotik.com/t/important-security-update/272851

[6] MikroTik Documentation – Device Mode és Flagged status https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode

[7] MikroTik Documentation – RouterBOARD és RouterBOOT firmware frissítés https://help.mikrotik.com/docs/spaces/ROS/pages/40992878/RouterBOARD