MikroTik RouterOS under attack: the exploited SSH flaws and what to do now

On 3 September 2026 MikroTik published a security update for RouterOS, the operating system of its routers, calling it “important” and saying nothing about what it fixed. Two days later CERT Polska, the Polish national incident response team that had found and reported the problems, broke the silence: six vulnerabilities, two of which combined let anyone take full control of the router without knowing a single password, as long as the SSH service is reachable from the internet. The attack chain has a name, MikroTrick, and it is already in use: the intrusions traced so far go back to at least 2 September, the day before the patches.

MikroTik routers are everywhere a solid network device at a modest price is needed: offices, professional practices, small providers, branch sites linked by VPN, colocation racks. Often a technician installed them years ago, they work, and nobody has opened them since. That is precisely the profile of device this story puts at risk.

Below: what was found, who is genuinely exposed and who is not, how to tell whether a router has already been breached, how to update and what to change in the configuration so it does not happen again. The facts come from the MikroTik bulletin, the CERT Polska advisory and the official documentation, all linked at the end.

What was found: six flaws, two are enough to get in without a password

The two vulnerabilities that make up the MikroTrick chain both affect the RouterOS SSH server, the service that lets you administer the router from a remote command line. Both are rated 9.2 out of 10 in severity.

CVE-2026-67276: when a user authenticates with a cryptographic key instead of a password, RouterOS did not verify the whole key, only part of it. Anyone who knows the public part of an authorised user’s key can build a different key the router accepts anyway, and log in as that user without holding the private key. It is a lock that checks the shape of the key but not the teeth.
CVE-2026-86060: the SSH login procedure mishandled usernames beginning with a disallowed character. With a crafted name, a session that should have limited permissions ends up with full administrator privileges.

Taken one at a time, each has prerequisites. Combined, according to CERT Polska, they allow “full control of the device without authentication”. The other four flaws are less severe but not negligible: one in the bandwidth-test service (the built-in bandwidth measurement tool, port 2000) lets an unauthenticated client read fragments of system memory or reboot the router; one in the WebFig web interface allows reading protected files, including configuration archives that contain credentials; the last two affect the built-in SSH client and X.509 certificate handling.

One detail explains the race against the clock: MikroTik released the fix without details, but RouterOS patches are public and can be compared. By 4 September an independent analysis was already online that, by diffing version 7.23.3 against 7.23.4, had reconstructed how the flaws worked. At that point staying quiet helped nobody, and CERT Polska published its advisory on the 5th.

Who is genuinely at risk (and who is not)

MikroTik writes that “most configurations are not at risk”. That is true, with one important caveat. A MikroTik router’s default configuration blocks access to management services from the WAN port, so a device installed with factory settings does not expose SSH to the internet and cannot be attacked from outside.

The problem is everyone else: routers configured from scratch by a technician, those where firewall rules were removed “to make something work”, those where SSH was opened for convenient remote management, those run by providers and data centres. The Shadowserver Foundation, a non-profit that scans the internet on behalf of national CERTs, counted roughly 122,500 MikroTik routers with SSH reachable by anyone on 5 September. Each of those, if not updated, can be taken with a script.

Many versions are affected. When a user on the official forum asked whether 7.20 and 7.21 were vulnerable too, MikroTik staff replied that “many years of versions” are affected: the fix exists only from the 3 September releases onward. How new the router is does not matter, how new the operating system is does.

How to tell whether the router has already been breached

Before updating it is worth looking, because the update closes the door but does not evict whoever is already inside. CERT Polska describes what the observed attacks leave behind:

the event log shows lines such as login failure for user -2 from <ip> via ssh followed shortly by user <name> added by ssh:-2@<ip>: that -2 in place of a username is the signature of the exploited flaw;
an unknown administrator account is created, called ops in the observed cases;
scripts, scheduled tasks, proxies or tunnels appear that nobody configured.

From the router console, these are the checks:

/log/print where message~"-2"
/system/history/print
/user/print
/system/script/print
/system/scheduler/print
/ip/proxy/print
/ip/socks/print

If the log has already been overwritten, and on a router that happens fast, the absence of suspicious lines proves nothing: what counts are the users, scripts and rules you do not recognise.

MikroTik added an extra safety net. On first boot, the fixed versions examine the configuration for known traces of compromise: if they find any, they disable the suspicious entries, write a critical message to the log and put the router into Flagged status. You check it with /system/device-mode/print. In that state the router keeps working, but it will not let you create new scheduled tasks, proxies, VPN tunnels or shares until someone intervenes in person: clearing the marker takes a command confirmed by pressing the physical reset button or power-cycling the device. The documentation is clear on two points: Flagged status does not delete the configuration, which still has to be inspected line by line, and the mechanism only recognises known traces, so an unflagged router is not necessarily clean.

What to do now: update, then verify

The fixed versions are 7.24.2 (stable channel), 7.23.4 (long-term), 6.49.21 for those still on the old version 6 series, and 7.25beta3 for the development channel. From the console:

/system/package/update/check-for-updates
/system/package/update/install

The router reboots by itself when done: on a production device you need a window of a few minutes. Before updating, export the configuration with /export file=before-update and download the file, for the same reason you take a backup before any intervention: if something goes wrong, you roll back.

After the update, not before:

check /system/device-mode/print and the event log for the Flagged message;
repeat the checks from the previous section on users, scripts, scheduled tasks, proxies and tunnels;
change every password on the router and regenerate the users’ SSH keys, because an attacker with administrative access may have read the full configuration, credentials included;
if the router acted as a VPN concentrator, treat the tunnel keys as compromised too and regenerate them.

If a router shows signs of compromise and you cannot reconstruct what was touched, the safest route is a factory reset onto the fixed version and a rebuild from a verified export taken before the incident.

Those who cannot update right away have a single temporary alternative, given by both MikroTik and CERT Polska: make SSH, the web interface (WWW and WWW-SSL) and the bandwidth-test service unreachable from outside. It shrinks the surface, it does not solve the problem.

Updating is not enough: management access must not be exposed

The most useful lesson in this story is not about MikroTik. A router’s administrative interfaces (SSH, WebFig, Winbox, the API) should never be reachable from the internet, regardless of the flaw of the day. It is the same principle by which a server’s SSH port is not exposed and by which automated password guessing, thousands of attempts a day against anything that answers, hits routers too: back in July CISA, the US cybersecurity agency, had already published two advisories on the RouterOS API, one of which notes that it does not limit failed login attempts.

In practice, the configuration we recommend and apply:

/ip/firewall/address-list/add list=management address=192.168.10.0/24
/ip/firewall/filter/add chain=input protocol=tcp dst-port=22,80,443,2000,8291,8728,8729 src-address-list=!management action=drop place-before=0
/ip/service/disable telnet,ftp,www,api,api-ssl
/tool/bandwidth-server/set enabled=no
/ip/ssh/set strong-crypto=yes

The first rule drops any connection to the management services that does not come from the internal administration network. The others switch off what is not needed. MikroTik staff, again on the forum, pointed out that restricting the source address in the service itself (/ip/service/set ssh address=...) is less effective than a firewall rule, because the firewall drops the packet before the service ever receives it.

For remote management the right answer is a VPN such as WireGuard, which RouterOS has integrated for years: you enter the tunnel with a key, and only from inside the tunnel can you reach SSH. It is also the explicit recommendation of the MikroTik bulletin. The rest is discipline: an inventory of devices with version and date of last update, and a rule that a router’s security updates are applied within days, as with any other software that holds up production.

In short

Six flaws in RouterOS, two of which together let anyone take a MikroTik router with SSH exposed without any credential, have been exploited in the wild since 2 September 2026. Versions 7.24.2, 7.23.4 and 6.49.21 fix them and add an automatic check that marks routers with known traces of compromise as Flagged. The factory configuration is not exposed, but tens of thousands of hand-configured routers are. Check the log and the users, update, change the passwords, and close management access from the internet for good by moving it inside a VPN.

# MikroTik RouterOS under attack: the exploited SSH flaws and what to do now