Is Your MikroTik Router Compromised? A Step-by-Step Check

You may have a MikroTik router compromised right now and not know it. Attackers are exploiting a live RouterOS flaw, and a compromised device keeps routing traffic normally the whole time. The attacker just holds a hidden account, a planted SSH key and full administrative control in the background. Here is how to find out whether that has already happened to you, and what to do next.

What’s actually going on

On 5 September, CERT Polska, Poland’s national cyber security team, gave a warning. A pair of RouterOS bugs, tracked as CVE-2026-67276 and CVE-2026-86060, can be chained together. Together they let an attacker log into an internet-facing MikroTik router over SSH, with no password and no private key. MikroTik calls the fix a routine security update. CERT Polska calls what is happening to unpatched devices an active attack, with exploitation from at least 2 September, a day before fixes reached every release channel.

The first bug sits in how RouterOS verified an SSH login key. It checked part of the key but not all of it. So an attacker who already knew a valid username and public key details could forge a different key and log straight in. No private key needed. The second bug let that forged session escalate further, through a flaw in how certain usernames get handled, to full administrative control. Neither bug alone hands over the device. Chained together, as CERT Polska found happening in the wild, they do.

Once inside, attackers follow a pattern. They create a new administrator account, most often named “ops”, then add their own SSH key so they can get back in later. Firewall rules get quietly adjusted too. None of that touches your existing admin password, so a routine credential rotation will not remove them.

Step 1: Update RouterOS

This comes first. An unpatched router is still exploitable while you investigate everything else. MikroTik has fixed versions available on every channel:

• Long-term channel: 6.49.21 or 7.23.4
• Stable channel: 7.24.2

Update via Winbox, WebFig or the command line, whichever your team normally uses. Do this on every internet-facing device first. A device left unpatched during an investigation can simply be re-compromised.

Step 2: Check for a MikroTik router compromised before you patched

Patching stops new intrusions. It does not remove an attacker already inside. A patched device can still be a MikroTik router compromised days earlier. Work through this checklist on each device:

• Search system history for the string “-2” in the SSH username field. This is a signature of the exploit tooling and should never appear in genuine login attempts.
• List local users and look for anything you did not create, especially an account named “ops”.
• Check installed SSH public keys against a list of keys your team actually issued.
• Review firewall and NAT rules for anything that opens unexpected ports or forwards traffic somewhere unfamiliar.
• Look at scheduler and script entries, since attackers sometimes add scheduled tasks to reinstall access after a reboot.

If you find anything on that list, do not simply delete the offending account and move on. Assume the whole device is untrustworthy.

Step 3: Rebuild, don’t just clean up

A MikroTik router compromised by this campaign needs more than a quick fix. Restore its configuration from a backup you know predates 2 September. Or reset it and rebuild from scratch. Change every credential the device had access to, not only its own admin password. Attackers with router-level control can often see traffic and credentials passing through it. Then reapply the patch before putting the device back on the internet.

Step 4: Reduce what’s exposed going forward

This incident is a useful prompt to ask a broader question. Does SSH, WebFig or Winbox actually need to be reachable from the public internet on this device at all? For most organisations, the answer is no. Restrict management access to a VPN or a trusted internal range. Keep only the services you genuinely need facing outward.

Check your other MikroTik-adjacent risk while you are in there too. The same September release fixed a separate WebFig path traversal bug that can leak credentials. It also fixed an unauthenticated bandwidth-test service that can crash a device or leak kernel memory, plus a flaw that lets forged TLS certificates get accepted. None of those needed the SSH chain to be dangerous on their own, so patching for MikroTrick and stopping there still leaves those doors closed only by luck. Treating luck as a plan is the gap proper vulnerability management is meant to close.

Finally, write down what you find and when, even if the answer is “nothing suspicious”. If a MikroTik router compromised at another organisation in your sector later makes headlines, a dated record that you checked your own devices matters almost as much as the checking itself, especially to a client, insurer or auditor.

If you are not confident which of your internet-facing devices still expose management interfaces they should not, that is exactly the gap an external network penetration test is designed to find, well before an opportunistic scanner does. Pairing that with proper attack surface management means you find devices like this one before a scanner run by someone else does.