On September 2, 2026, MikroTik owners started posting odd lines from their router logs on the MikroTik forum and Reddit: a failed SSH login for a user called -2, immediately followed by a new user being added. A day later MikroTik shipped fixed RouterOS builds without much fanfare. On September 5 CERT Polska published the story: two chained bugs, now called MikroTrick, give an attacker full admin on any RouterOS device whose SSH service they can reach. No password, no key.
On September 10 CISA added two of the disclosed bugs, CVE-2026-86060 and CVE-2026-67277, to its Known Exploited Vulnerabilities catalog with a three-day remediation deadline. On September 25 it added the rekey bug, CVE-2026-67279, as well, so both halves of the chain are now on the list. If you run a MikroTik anywhere (home lab, office, a VPS edge on CHR), this is a 15-minute job: find out whether SSH is exposed, check the version, look for the known indicators, patch, and move management behind a VPN. Every command below is copy-pasteable into a RouterOS terminal or your own shell.
You need: admin access to the router (Winbox, WebFig or a local SSH session), a machine outside your network for the exposure check (a VPS or a phone hotspot) with nmap and nc, and a WireGuard client on your laptop for step 5. Steps 1 to 4 fit in 15 minutes; the WireGuard setup takes a few more if you have never done it.
What the chain does
CERT Polska's technical analysis describes two bugs that only matter together:
- CVE-2026-67279: the SSH server mishandled key re-exchange (rekeying) during user authentication. If the client started a rekey mid-auth, the server moved on to channel handling without ever sending
SSH_MSG_USERAUTH_SUCCESS. In other words, authentication could be skipped. - CVE-2026-86060: the login helper did not handle usernames that start with a disallowed character. A username of
-2gets parsed as a command-line argument, so the helper reads its identity from file descriptor 2 and the attacker controls the policy mask, which means full admin rights.
Two other CVEs from the same disclosure get mixed up with MikroTrick. CVE-2026-67276 (CVSS 9.2) is a separate SSH bug: RouterOS did not properly verify public keys, so someone who knows an account name and its RSA public key could log in as that user. CERT notes that some publications wrongly tied it to the chain. CVE-2026-67277 (CVSS 8.8) is in the bandwidth-test service, which let an unauthenticated connection reach a state that should need a login; combined with two smaller flaws it leaks kernel memory or crashes the device. It is not part of the chain, but it is on CISA's KEV list too. The KEV entries from this disclosure are CVE-2026-86060, CVE-2026-67277 (both added September 10) and CVE-2026-67279 (added September 25); CVE-2026-67276 is not listed.
Vulnerable: neither MikroTik nor CERT publishes an exact affected range (CERT's lab covered releases from 6.43.11 onward), so treat every build older than the fixed ones as vulnerable. Fixed builds, released September 3:
- 6.49.21 (v6 long-term)
- 7.23.4 (v7 long-term)
- 7.24.2 (v7 stable)
- 7.25beta3 (testing)
CERT has not published the full exploitation procedure, but the bug classes are now public, and exploitation in the wild started a day before the patch existed. Assume anyone can do this now.
Step 1: is SSH reachable from the internet? (2 minutes)
Check from a machine outside your network (a VPS or a phone hotspot) against your public IP. RouterOS identifies itself in the SSH banner:
# replace with your router's public IP
ROUTER=203.0.113.10
# SSH, Winbox, bandwidth-test ports
nmap -Pn -p 22,8291,2000 --open "$ROUTER"
# grab the SSH banner; RouterOS answers with SSH-2.0-ROSSSH
# (use the port SSH actually listens on if it is not 22)
nc -w 3 "$ROUTER" 22
If SSH answers with ROSSSH, you are in scope for MikroTrick. MikroTik's default configuration blocks management ports from the WAN side, so an exposed port usually means someone opened it by hand, or moved SSH to another port. If you did that, scan every port and let nmap read the banners, so SSH shows up as ROSSSH wherever it listens: nmap -Pn -sV -p- "$ROUTER".
Step 2: which version are you running? (1 minute)
/system resource print
/system package update print
Compare version with the fixed list above. Anything older than 6.49.21 on v6, older than 7.23.4 on long-term, older than 7.24.2 on stable, or older than 7.25beta3 on testing is vulnerable.
Step 3: look for the published indicators before you patch (5 minutes)
CERT Polska published this log pattern for a successful attack:
login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>
In the cases they saw, the new account was named ops and placed in the full group. Shortly afterwards the attacker created RouterOS diagnostic (.rif) files and pulled them out with fetch. The observed source IPs were 82.192.72.4 (successful attacks, since at least September 2) and 103.102.31.18 (exploitation attempts). Check all of it:
/log print where message~"user -2"
/log print where message~"82.192.72.4"
/log print where message~"103.102.31.18"
/user print detail
/user print where name="ops"
/user ssh-keys print
/system script print
/system scheduler print
/file print where name~"rif"
One caveat: RouterOS keeps logs in memory by default, so a reboot erases them. If you forward logs to syslog, search there too:
grep -E 'user -2|82\.192\.72\.4|103\.102\.31\.18' /var/log/mikrotik*.log
If you find a hit, do not just patch and move on. CERT's advice is to isolate the device, save the logs and configuration first (they are evidence), then factory-reset and rebuild from a trusted backup with new credentials. To save what is there right now:
/log print file=incident-log
/export file=incident-config
Then copy both files off the router (Winbox Files, or scp from a trusted host).
