How to Check Your MikroTik Routers for MikroTrick

October 1, 2026 · by Maddie Beaton

On September 5 CERT Polska published details of MikroTrick, a pair of bugs in RouterOS’s SSH server that let anyone who can reach SSH on a MikroTik log in with full admin rights. The attacker doesn’t need a password, an SSH key or any knowledge of how the router is set up. It’s been used against real routers since at least September 2 (the day before MikroTik released the fixes), and CISA added it to its Known Exploited Vulnerabilities list on September 10.

Most WISPs have MikroTiks somewhere in the network, and a lot of them haven’t been upgraded yet. On September 30, nearly four weeks after the fixes came out, more than 90% of the MikroTiks we monitor on our customers’ networks were still running an affected version.

We also went back through the configuration backups we keep for those routers and found 11 that attackers had already put backdoors on, with another 7 that look likely. None of them matched the indicators in the published reports, because the attackers had turned logging off or cut it back first and used other usernames. So along with the official guidance, this post covers how to check your own routers for that kind of thing and how to clean one up, whether or not you use Swift Fox.

If you only have a few minutes, the short version is to upgrade every MikroTik to 6.49.21, 7.23.7 or 7.24.4, make sure SSH on each one can only be reached from your own management addresses, and then check each router for users, scripts and schedulers you didn’t add, since upgrading doesn’t remove anything an attacker already set up.

What is MikroTrick?

MikroTrick is CERT Polska’s name for two RouterOS bugs used together, CVE-2026-67279 and CVE-2026-86060. Their technical analysis from September 22 goes through it in detail, but here’s roughly how it works.

The first bug (CVE-2026-67279) is in how RouterOS handles an SSH rekey. An SSH connection normally goes through key exchange, then user authentication, and only after that can the client open a shell or run a command. If the client asks for a rekey partway through authentication, vulnerable versions move straight on to the command stage once the rekey finishes, instead of going back to authentication. That lets the attacker open a session without ever logging in.

The second bug (CVE-2026-86060) turns that session into full admin access. The attacker uses -2 as the username, which RouterOS passes along to its internal login program, and the login program reads -2 as an instruction to take the user details from file descriptor 2. That file descriptor is the same terminal the attacker is typing into, so they can send whatever username and permission mask they like, and they send the mask for the full group.

Because the attacker never authenticates, the usual SSH hardening doesn’t help. Strong passwords, key-only logins and strong-crypto don’t make any difference, and CERT mentions an administrator who had an admin account created on routers that were set up with SSH keys only and strong-crypto turned on. Running SSH on a non-standard port might keep a router out of the quickest scans, but it’s still exploitable. What matters is whether the attacker can reach the SSH service at all.

Some of the early news coverage named CVE-2026-67276 as part of the chain, and you’ll still see that repeated. CERT has since said that was wrong. 67276 is a separate bug that lets someone impersonate a user who logs in with an RSA key, but it needs that user’s name and public key, so it isn’t much use for attacking routers in bulk. It’s fixed in the same releases, so it doesn’t change what you need to do.

CERT found these bugs using LLM-based agents testing RouterOS virtual machines in a lab, and their write-up points out that independent researchers had rebuilt working exploits from MikroTik’s patches within two days of the release. Their conclusion is that the time between a security release and attacks against it is getting a lot shorter, so RouterOS security releases are worth installing within days rather than at the next maintenance window.

Which RouterOS versions are affected?

Both bugs affect every RouterOS 6 and 7 release before the fixed versions MikroTik put out on September 3, which are 6.49.21 for v6, 7.23.4 on the long-term channel and 7.24.2 on stable. MikroTik’s advisory and CERT’s list of the CVEs have the details.

CERT disclosed four more RouterOS bugs at the same time, and three of them matter when you pick a version:

CVE-2026-67277 lets anyone who can reach the bandwidth test server start a UDP test without authenticating. It affects v6 too, so if you run /tool bandwidth-server it should have authenticate=yes, or be turned off if you don’t use it.
CVE-2026-67281 is an unauthenticated file read in WebFig on 7.20 and newer, which is another reason to restrict www and www-ssl the same way as SSH.
CVE-2026-67278 is a flaw in RSA signature checking on v7 (TLS certificates and SSH host keys). The fix in 7.23.4 and 7.24.2 was incomplete, and it was finished in 7.23.6 and 7.24.3.

7.23.6 and 7.24.3 then had a bug that deleted the LTE modem firmware on some LTE models, which MikroTik fixed in 7.23.7 and 7.24.4 on September 16. So for v7 routers we’d go straight to 7.23.7 (long-term) or 7.24.4 (stable), or anything newer. v6 routers need 6.49.21.

What to do first

Upgrade. If you have a lot of routers to get through, start with the ones where SSH can be reached from the internet or from customer networks.

Lock down SSH. Even after upgrading, SSH should only be reachable from the addresses you manage your routers from. In RouterOS that’s /ip service set ssh address= with your management subnets, or an input firewall rule that drops SSH from everywhere else. It’s worth keeping that list fairly tight. Allowing all of 10.0.0.0/8 or every private range often takes in customer CPEs and other devices you don’t control, and on a lot of WISP networks subscribers can reach the router’s own addresses. The same goes for Winbox, WebFig and the API. About 40% of the MikroTik configurations we back up had no address restriction on SSH and no input drop rule. Not all of those are reachable from the internet, since a lot of them sit behind other routers, but SSH on them is open to anything that can route to them.

If your monitoring system logs in to your routers over SSH (Swift Fox does), add its address to the list rather than leaving SSH open for it. For Swift Fox that’s the address of your pingbox, and on a Pathbox network it’s usually the Pathbox itself.

Send your logs somewhere else. RouterOS keeps its log in memory by default, so it’s gone after a reboot, and it was the first thing the attackers we saw went after. If you add a remote logging action pointing at a syslog server, you’ll have a copy of the log that nobody on the router can change later.

Is upgrading enough?

No. Upgrading closes the hole, but anything an attacker already added stays where it is. Four of the 11 routers we found are on fixed firmware now, and three of those still have the backdoor in their configs.

MikroTik also added a check to the fixed v7 releases. At boot, if RouterOS finds a user called ops in the full group (the account CERT saw attackers create), it disables that user and marks the router as “Flagged”, which shows up in /system device-mode print and in the log. A flagged router keeps passing traffic, but it won’t let anyone add schedulers, SOCKS, proxies or VPN tunnels until the flag is cleared.

That’s helpful, but as CERT describes it the check only looks for ops, and the backdoors we found use other usernames. People on MikroTik’s forum also report that the flagged value comes back empty on 6.49.21, so it doesn’t look like v6 has the check at all. A router that isn’t flagged hasn’t necessarily been left alone.

How to check a router

These all work on v7, and most work on v6 as well:

# firmware version
/system resource print
# v7: did RouterOS flag the router at boot?
/system device-mode print
# users, SSH keys, and who's logged in right now
/user print detail
/user ssh-keys print
/user active print
# scripts, and everything that can run one
/system script print detail
/system scheduler print detail
/tool netwatch print detail
/ppp profile print detail
# SSH settings, and which addresses can reach each service
/ip ssh print
/ip service print detail
# proxies, dynamic DNS, NAT, VPN servers and tunnels
/ip socks print
/ip socks users print
/ip proxy print
/ip cloud print
/ip firewall nat print detail
/interface pptp-server server print
/ppp secret print
/interface print
# logging (look for disabled rules or memory-lines=1)
/system logging print
/system logging action print
# files saved or downloaded on the router
/file print
# bandwidth test server (CVE-2026-67277)
/tool bandwidth-server print
# the MikroTrick log trace, if the log hasn't been cleared
/log print where message~"user -2|ssh:-2@"

What you’re looking for is anything you didn’t set up yourself. That means users and SSH keys you don’t recognise (especially in the full group), scripts you didn’t write along with the schedulers, netwatch entries and PPP profiles that run them, and any script that contains /user add, /user ssh-keys import, /tool fetch followed by /import, /log remove, /system backup save, /export file= or /system package update. After that, check for SOCKS, proxy, DDNS, NAT rules, VPN servers, PPP secrets or tunnels you didn’t add, SSH on a port you didn’t pick, logging that’s been turned off, and .rsc, .backup or .rif files you didn’t create. An empty log doesn’t mean nothing happened, since the log is in memory and a lot of the routers we found had theirs cut.

If you have more than a handful of routers, it’s a lot quicker to pull /export from each one over SSH and search the results for the patterns above than to go through them one at a time in Winbox. The /user, /user ssh-keys, /file and /log checks still need doing on each router though, since none of those are in an export.

Cleaning up a compromised router

Before you change anything, save a copy of the router’s export and log somewhere off the router, since you might need them later to work out what the attacker had access to. If the router can wait, take it off the internet or lock down its management access first.

CERT’s advice is a factory reset and reconfiguring from a trusted backup, and that’s what we’d do too. For core and edge routers we’d netinstall, which wipes the whole flash including any files the attacker left behind, and then re-apply the configuration from a text export taken before September 2, or the current export reviewed line by line. A binary .backup taken after the compromise brings the attacker’s users and scripts back with everything else.

If you can’t reset a router right away, remove things in this order so nothing gets re-created while you’re working on it:

Whatever runs the attacker’s scripts (schedulers, netwatch entries, and on-up or on-down scripts on PPP profiles), then the scripts themselves.
Unknown users and SSH keys.
SOCKS users and settings, NAT rules, VPN servers and PPP secrets you didn’t add, tunnels, DDNS and any files the attacker saved.
Put your logging back, upgrade, reboot, and then run the checks again.

Then rotate every secret the router had. That includes admin passwords, PPPoE and hotspot secrets, RADIUS shared secrets, IPsec and WireGuard keys, SNMP communities, wireless keys, and any password that’s shared with other routers (including the one your monitoring system logs in with). If you find a script or scheduler on a router that saves exports or backups to files, assume whatever it saved has been taken.

On v7, a flagged router needs /system device-mode update flagged=no once it’s clean, and RouterOS will ask for either a press of the physical button or a hard power cycle to confirm it. For a tower router that probably means a site visit or a remote power switch, so it’s worth planning for.

How Swift Fox alerts on MikroTrick

Every MikroTik we monitor is now checked for two things, and both show up as warnings in the “Infra Issues” tab on the netmap and on the device’s details page. Clicking an issue opens its full details, including a link to MikroTik’s advisory.

The first is its firmware version. A router running a version affected by MikroTrick gets a “Security:Vulnerability” issue, which clears on its own once the router’s been upgraded.

The second check runs every 6 hours alongside the config backup. It looks for RouterOS’s Flagged status, an ops user in the full group and the -2 lines in the log, and it also goes through the configuration for scripts that create full-access users, download and run config, import SSH keys or delete log lines, along with the specific names and addresses we found on our customers’ routers. Anything like that raises a “Security:Compromise” issue. A log that’s been cut down to a single line gets the same issue marked “Possible” instead, for someone to take a look at.

It picks up all 11 routers from our sweep (one of them only as “Possible”, since its backdoor script had already been removed before we looked) and one of the 7 likely ones, so the other six need checking on the router itself. A clean result isn’t proof though, since an attacker who only added a user or an SSH key doesn’t change the export.

Neither check pages anyone for now. The vulnerability one starts out covering nearly every MikroTik on most networks, and we’d rather talk it through with our customers before a new check starts waking people up.

The configuration history for each router goes back well before September 2, so you can also select any MikroTik on the netmap, open its “Configs” tab and pick two backups (one from August and one from today) to see everything that’s changed in between.

If you’re a Swift Fox customer and one of your routers turned up in our sweep, we’re getting in touch with you directly. The checks are part of our Network Management tier, and if you’d like them running on your own network, reach out and we’ll set up a trial. And if you’ve found something on your own MikroTiks that isn’t covered here, we’d love to hear about it, so we can add it to the checks and to this post!