MikroTik updated after MikroTrick? Also check for ‘flagged’ in RouterOS

In early September 2026, CERT Polska disclosed a chain of RouterOS vulnerabilities under the name MikroTrick. Two of the six vulnerabilities identified are critical: when combined, they give an attacker without login credentials full control over a MikroTik router, provided that SSH is accessible from the internet. MikroTik released a patch even before the technical details were published, but active exploitation was already underway at that point.

Most administrators are now aware that they need to update their systems. What is less well known is that RouterOS has a built-in detection feature that can tell you whether your specific router has already been compromised before you applied the patch. This status is called flagged, and you can check it with a single command.

This article is not about the vulnerabilities themselves. It’s about what you need to do after the update: check whether your router has already been compromised, and what you should do next if that’s the case.

A quick way to check if your MikroTik is flagged

Log in to your router via SSH, the Winbox terminal or the console, and run the following command:

/system/device-mode/print

Sample output from a router showing no signs of misuse:

mode: advanced
allowed-versions: 7.13+,6.49.8+
flagged: no
flagging-enabled: yes

The rule you’re looking for is flagged. There are two possible values:

• flagged: no - RouterOS has not detected any known signs of unauthorised modifications.
• flagged: yes - RouterOS did detect such signs during start-up.

flagged: no is a good sign, but it is no absolute guarantee that the device has never been compromised. The detection system recognises known patterns, not unknown ones. Later in this article, I’ll explain why you should still carry out a quick check even then.

What does ‘flagged: yes’ mean on a MikroTik?

Upon start-up, RouterOS scans the configuration for known signs of unauthorised changes. If the system detects such a sign, three things happen: the recognised suspicious configuration is disabled, a critical message is logged, and the flagged status is set to yes.

A ‘flagged: yes’ should be treated as a potential compromise until proven otherwise.

It is important to understand that the flag itself is not the problem. The flag is simply the alert that is triggered because something has been detected. You will need to investigate the underlying problem yourself – exactly how an attacker gained access and what they did.

What can’t you do when RouterOS is flagged?

As soon as a router is flagged, RouterOS deliberately blocks a number of functions to limit further opportunities for abuse. These include:

• bandwidth test
• traffic generator
• packet sniffer
• new or additional scheduler configuration
• SOCKS
• PPTP
• L2TP
• IPsec
• proxy
• SMB

The key point here is that existing, non-suspicious configurations will, for the most part, continue to run as normal. The router will not automatically go offline, and customers connected to the router will, in most cases, not notice anything. Suspicious configurations that have already been detected have already been disabled or removed by RouterOS itself. The block primarily applies to the creation of new high-risk configurations, not to the operation of your existing, clean setup.

What should you do if ‘flagged: yes’ appears?

Proceed systematically. Do not clear the flag as your first step.

1. Do not clear the flag straight away.
2. Check users.
3. Check scripts.
4. Check scheduler entries.
5. Check services.
6. Check the input firewall.
7. Check NAT rules.
8. Check logs.
9. Remove or disable any unknown configuration.
10. Update RouterOS to a patched release.
11. Change relevant credentials and secrets.
12. Only then should you remove the flagged status.

To do this, use the following commands.

/user/print detail

Look out for accounts you do not recognise, unusual names, or users with more privileges than you would expect. In previous MikroTik breaches, accounts with short, generic names – created via a compromised SSH session – have been found, amongst other things. A single specific username is not a universal indicator, so focus on what you do not recognise yourself, rather than on a single familiar name from a news report.

/system/script/print detail

Look for scripts that you haven’t written yourself, particularly those that connect to external networks, create users or modify firewall rules.

/system/scheduler/print detail

Scheduler jobs run in the background without you having to think about them all the time. A job you don’t recognise that calls a script is a strong indication of something being amiss.

/ip/service/print

Check which management services are active and where they can be accessed from. Have SSH, Winbox or WebFig been made more accessible than you intended?

/ip/firewall/filter/print detail

Look for rules that you haven’t added, particularly those that allow traffic on management ports from 0.0.0.0/0.

/ip/firewall/nat/print detail

Check for unexpected port forwards, particularly to internal management interfaces.

/log/print where topics~"critical"

Critical log messages often show the exact time and nature of the change detected.

/log/print where message~"flagged"

Filters directly for the log message corresponding to the moment when RouterOS set the flag.

Go through this list before you continue. If you find anything unfamiliar, delete or disable it, and make a note of what you’ve found in case you do need to carry out a forensic investigation later on.

Why shouldn’t you run ‘flagged=no’ straight away?

This is the crux of this article. Removing the flag without first carrying out an investigation is like switching off the alarm without checking why it went off.

‘flagged: yes’ is not the error message you need to resolve. It is a warning that you need to look into something.

As long as you leave the flag in place, you know: something was found here at some point, and until I’ve proven otherwise, I’ll treat this device as if it may have been under someone else’s control. As soon as you clear the flag without investigating, you lose that indicator and carry on as if nothing had happened, even though you cannot be certain.

How do you remove ‘flagged: yes’?

Once your research is complete and you are satisfied with what you have found and organised, you can remove the flag by:

/system/device-mode/update flagged=no

This cannot be completed entirely remotely. RouterOS requires physical confirmation, depending on the model:

• pressing a physical button on the router, or
• a proper power cycle: switching the power off and on again, or performing a hard reboot of the virtual machine at CHR.

/system/reboot

This is explicitly not the same thing. A standard reboot using this command does not trigger a physical reset when RouterOS specifically requires one.

This has been deliberately designed this way. An attacker with only remote access must not be able to simply dismiss the compromise warning themselves. Without physical intervention, the flag remains in place, even if the attacker has full control of the RouterOS configuration.

Please note regarding routers at remote locations

This is where things get tricky in practice for MSPs and multi-site administrators. Auditing and clean-up can largely be carried out remotely: verifying users, running scripts, checking scheduler jobs, updating RouterOS, changing credentials – all of this can be done remotely via SSH or Winbox.

The final step – the actual confirmation of flagged=no – may require physical access. This is particularly relevant for:

• data centres
• POP locations
• customer sites without their own technical staff
• remote sites without a permanent on-site administrator
• MSP environments with widely dispersed equipment

Make a note of this. If you have several remotely flagged routers, you’ll know after the first one whether you need someone on site, or whether you need to wait until a scheduled maintenance visit.

What does ‘flagged: no’ mean?

A positive result, but no substitute for a security audit. The detection system recognises known patterns from known attacks. A new or different method could, in theory, go undetected.

Therefore, even when ‘flagged: no’ is set, please carry out the basic check:

/user/print detail
/system/script/print detail
/system/scheduler/print detail
/ip/service/print

This takes a few minutes and gives you a level of certainty that the flag alone cannot provide.

Check SSH, Winbox and management access

The MikroTrick chain relied on SSH being accessible directly from the internet. Management services such as SSH, Winbox, WebFig and the API should preferably not be exposed directly to the public internet. The most secure setup is access via a trusted management network or via a VPN, such as WireGuard [internal link: WireGuard].

Check which services are running:

/ip/service/print

Please note: the available-from column in this output does not tell the whole story. A service may appear to be restricted there, whilst the firewall still allows the traffic through, or vice versa. You should therefore also check the input firewall itself:

/ip/firewall/filter/print detail where chain=input

The ingress firewall ultimately helps determine which services are actually accessible from the internet, regardless of what /ip/service/print suggests. For a more comprehensive approach to your firewall rules, see [internal link: firewalling] and, if you’re working with multiple routers and routing domains, [internal link: BGP]. If you want to set up new VLAN, firewall or WireGuard configurations straight away from here, use the MikroTik Config Generator for ready-to-use RouterOS commands.

Which RouterOS versions include the fix?

MikroTik released the fix in the following releases:

• 7.25 beta 3
• 7.24.2
• 7.23.4
• 6.49.21

When this article is published and whenever you read it, please always check the latest status via the official MikroTik advisory; release notes are subject to change and further patches may follow these releases.

A handy five-minute check

A concise overview to put into practice straight away:

/system/device-mode/print
/user/print detail
/system/script/print detail
/system/scheduler/print detail
/ip/service/print
/ip/firewall/filter/print detail where chain=input

flagged: no
That’s a good sign. Have a quick look through the rest of the output to check for anything you don’t recognise.

flagged: yes
Do not unflag immediately. Treat the device as potentially compromised, investigate its configuration, remove any unauthorised items, update to a patched release, change the credentials, and only then lift the flag following physical verification.

Conclusion

Updating isn’t the end goal; it’s the first step. It’s the order that counts:

Update, check for flagged items, audit the configuration, check management access.

And the crux of this article in a single sentence: ‘flagged: yes’ is not the problem you need to hide, but the signal you need to investigate.

For more background on securing MikroTik devices and RouterOS in general, see [internal link: MikroTik security] and [internal link: RouterOS]. If you manage multiple routers or a wider network that includes Linux devices, please also take a look at [internal link: Linux network management] and [internal link: network security]. If you’re looking for personalised assistance with setting up or auditing your MikroTik environment, please see MikroTik Network Consultancy.

External sources

• MikroTik – September 2026 vulnerability
• CERT Polska - Critical vulnerabilities in MikroTik RouterOS are being actively exploited
• MikroTik RouterOS Manual - Device mode