Hole in MikroTik: SSH hands over the whole router

CERT Polska published six vulnerabilities in MikroTik RouterOS on 5 September 2026. Two of them chain together and hand an attacker full administrator rights through the MikroTik RouterOS SSH service, with no password and no private key. The team named the chain MikroTrick. Attacks on devices whose SSH port is reachable from the internet have been running since at least 2 September, and patched releases are already available.

How the MikroTik RouterOS SSH chain works

The first flaw is an SSH authentication bypass. RouterOS matches an incoming key against an authorised RSA key by comparing the key type and the modulus, but not the exponent, and it verifies the signature using the key the client supplied. An attacker who knows a valid username and the public part of that user's RSA key can build a key with exponent one, sign the request with it and open a session as that user. No private key and no password are involved.

1. The attacker connects to a router whose SSH service answers on the public internet.
2. A forged RSA key passes the incomplete comparison and opens a session as an existing user.
3. A username starting with a prohibited character slips through argument handling in the login helper.
4. The policy mask of the session is rewritten, and the session ends up with full administrator rights.

The two links are tracked as CVE-2026-67276 (signature verification) and CVE-2026-86060 (argument handling), both rated 9.2. The remaining four cover an unauthenticated bandwidth test that leaks memory, X.509 validation, unauthenticated SSH commands and an uninitialised pointer in WebFig file authorisation.

How to tell whether your router was taken

CERT Polska published concrete indicators, and they are easy to check on the router itself.

• Log entries: lines reading login failure for user -2 from <ip> via ssh, or a successful session shown as ssh:-2@<ip>.
• A new account: a privileged user named ops that nobody in your team created.
• Configuration changes: new SSH keys, scripts, schedulers, services, firewall rules, proxies, tunnels or packet sniffing settings in /system history.
• Known addresses: connections from 82.192.72.4 or 103.102.31.18.

If the signs are there, the advice is to take the device off the network and preserve the logs before doing anything else. A factory reset removes the attacker's account, but it also removes the evidence, and any password or key that lived on that router should be treated as known to someone else.

Changing the admin password is the step people reach for first, and on its own it fixes nothing. An account added by somebody else stays, an SSH key added to an existing user stays, and so do scripts, schedulers, firewall rules and tunnels that were written into the configuration while the attacker had administrator rights. That is why the recommendation is an audit of the whole configuration, or a rebuild from a backup made before the device was exposed.

The exposure also looks different in an office and at home. A provider or a company usually keeps management on a separate interface and notices a new account through monitoring, so the risk there is mostly the time between the disclosure and the maintenance window. A home or small-office router more often has SSH opened by hand for remote access, no monitoring behind it, and nobody who reads the log until something breaks.

Which RouterOS versions are fixed

If updating right now is not an option, the interim measure is to stop answering strangers: disable the SSH and WebFig services or restrict them to a management address, and check that the router is not publishing them to the whole internet. Home units ship with firewall rules that block management ports from the WAN side, so the devices at risk are mainly those where somebody opened the port deliberately, often to reach the router from outside.

What it means for a home VPN

MikroTik is not only an office brand. The cheap hEX and hAP boxes are a common way to run a personal VPN endpoint at home, with WireGuard, IPsec or L2TP terminating on the router itself, and remote access over SSH is exactly why the port ends up open. When the router is the VPN server, whoever owns the router owns the tunnel: they can read what leaves the tunnel, add their own peers and watch the traffic of every device behind it. A commercial VPN app running on a laptop still encrypts that laptop's traffic to the provider, but it does not clean a router that already has somebody else's account on it.