Security3 publishers2 min readPublished
MikroTik's new RouterOS builds check whether the device was already compromised
MikroTik published RouterOS fixes in four branches with no CVE and no technical detail. The same upgrade runs a compromise check and writes a critical log entry marking the device Flagged.
The Watch · Security desk
What happened
- MikroTik says it found a security vulnerability in RouterOS and shipped the fix in 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21 and newer, across all release channels.
- The vendor is holding back the technical detail, saying it is not currently publishing it in order to give operators time to update their systems.
- MikroTik tells every operator to inspect the device for unknown scripts, users or unrecognised configuration after upgrading, whether or not the router came back Flagged.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- capability Each upgraded router now reports on its own history, so an operator with no central logging can still find out whether the device was taken before the patch landed.
- constraint With no CVE and no mechanism, defenders cannot write detection for the exploit attempt or test their own configuration against it; patching and manual config review are the whole toolkit.
- decision A Flagged entry converts a maintenance window into an incident, and the operator has to choose between auditing the running configuration line by line and rebuilding the router.
- exposure MikroTik's assurance that most configurations are not at risk lets no one rule themselves out, because the at-risk configurations are unnamed.
The Flagged status is the part of this advisory worth reading twice. MikroTik wrote that RouterOS "will check if your device has been compromised" [6], and that a compromised device gets a critical entry in the Log section pointing to the Flagged status documentation [5]. Writing that check requires knowing what a compromised device looks like in configuration or on disk.
MikroTik published the fixed version numbers, the compromise check and the instruction to inspect configuration [3][5][7]. It did not publish a CVE identifier, the mechanism, the list of affected configurations, or any statement that the flaw has been used against a customer [13]. On the withholding, MikroTik wrote: "To give time to update your systems, we are not currently publishing detailed information" [2].
The fix is in 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21 and newer [3]. Three of those four branches sit in the 7.x line and the fourth is in the RouterOS 6 line, so the vulnerable code is present in both major versions [12].
The upgrade closes the hole and leaves attacker-added configuration in place. MikroTik says Flagged status does not delete configuration [8], and tells operators to inspect the device for unknown scripts, users or other config they do not recognise whether it is Flagged or not [7]. The build is offered on the device itself, through the "Check for updates" menu [10].
MikroTik says regular home users and default configurations face no immediate risk, and still suggests every user upgrade [9]. Its post also says "Most configurations are not at risk, but upgrading is highly recommended" [4], without naming the configurations that are. MikroTik says the announcement will be updated with more information in due time [11].
What to watch
- A CVE identifier and an affected-configuration list from MikroTik would tell operators whether they were ever reachable.
- Any count of Flagged devices, from operators or from internet scanning projects, would size the intrusion set.
- Whether the fix reaches further 6.x builds or a 7.25 stable release beyond the beta named in the advisory.