MikroTrick: MikroTik's RouterOS Bugs Under Attack

If you manage a MikroTik router and haven’t touched RouterOS since August, stop reading and go check your version number. Three vulnerabilities patched on September 3 are already being exploited in the wild, and CISA confirmed it a week later by adding two of them straight to its Known Exploited Vulnerabilities catalog.

What is MikroTrick?

MikroTrick is a chain of three RouterOS bugs that, together, let an attacker with zero valid credentials walk away with full administrative control of a router. Two of the three (CVE-2026-67276 and CVE-2026-86060) attack the SSH login path itself. The third (CVE-2026-67277) doesn’t even need SSH credentials, it hits an unauthenticated service that’s supposed to be harmless. CERT Polska, the Polish national CERT, confirmed exploitation and coined the name after tracing attacker activity back to September 2, the day before MikroTik shipped a fix.

That timeline matters. A patch that ships a day after exploitation starts isn’t really a patch window, it’s a race that most defenders already lost by the time they read about it.

The three bugs, in plain terms

CVE-2026-67276 (CVSS 9.2), SSH key confusion. RouterOS is supposed to verify that the SSH key presented during login matches the exact key on file for that user. It doesn’t verify tightly enough. An attacker who already knows a username and the public modulus of that user’s registered key (both of which can leak through misconfigured key management or prior recon) can craft a different key that RouterOS accepts as if it were the real one.

CVE-2026-86060 (CVSS 9.2), privilege escalation via username. This one is almost absurdly simple once you see it. RouterOS builds an internal policy mask from the username during SSH login. If the username starts with a character it shouldn’t accept, that mask construction breaks in a way that grants the session administrative rights it was never supposed to have. Combine this with 67276 and you don’t need a real admin account at all, you need a crafted key and a crafted username.

CVE-2026-67277 (CVSS 8.8), bandwidth-test memory disclosure. Separately, RouterOS’s bandwidth-test service accepts a “related” connection before the primary session finishes authenticating. An unauthenticated client can start a UDP test against the router and, with the right parameters, either leak kernel memory or force the RouterOS kernel to restart. No SSH access needed for this one at all, it’s a straight network-facing bug.

None of these require the attacker to be anywhere near the router physically. If SSH or the bandwidth-test service is reachable from the internet, that’s the whole attack surface.

Who’s exposed, and how many routers that actually is

Internet-wide scans put the number of MikroTik devices with SSH reachable from the open internet above 122,500. Brazil accounts for roughly 11,300 of those, the US and Indonesia around 7,100 each, Czechia about 6,300, and Ukraine around 5,100. That’s not a niche edge case, it’s a meaningful slice of the internet’s router population sitting exposed to a bug that was actively exploited before a patch existed.

If your RouterOS device only accepts SSH from an internal management VLAN or a VPN, your exposure is much smaller (though CVE-2026-67277’s bandwidth-test issue is worth checking regardless of SSH exposure, since it’s a separate, unauthenticated attack surface).

Are you affected?

You’re exposed if you’re running any RouterOS version on the 6.49, 7.23, 7.24, or 7.25 lines older than the fixed releases below, and either SSH or the bandwidth-test service is reachable from an untrusted network.

RouterOS branch	Vulnerable	Fixed in
Long-term (6.x)	6.49.20 and earlier	6.49.21
Long-term (7.23.x)	7.23.3 and earlier	7.23.4
Stable (7.24.x)	7.24.1 and earlier	7.24.2
Testing (7.25.x)	7.25beta2 and earlier	7.25beta3

Patch, then check for prior compromise

Patching closes the door, but if exploitation started September 2 and you’re only patching now, you should assume someone may have already walked through it.

1. Upgrade RouterOS first. Update to 7.24.2, 7.23.4, or 6.49.21 depending on your branch. This is the only fix; there’s no workaround that fully closes CVE-2026-86060 or CVE-2026-67276 short of disabling SSH entirely.
2. Grep your logs for the exploitation signature. CERT Polska has published login failure for user -2 from <ip> via ssh user <name> added by ssh:-2@<ip> as a marker tied to attempted exploitation. If you see it, treat the device as potentially compromised even if the login ultimately failed.
3. Look for an unexpected ops user. That’s the account name researchers have observed attackers creating post-compromise to maintain access. Check /user print for anything you didn’t create.
4. Audit scheduled tasks and scripts. RouterOS’s scheduler is a common persistence mechanism once an attacker has admin rights. Run /system scheduler print and /system script print and account for every entry.
5. If you can’t patch today, restrict exposure now. Firewall SSH, WWW, and the bandwidth-test service to a trusted management network, or disable them on the WAN interface entirely, until the upgrade window opens.

Why this keeps happening to network appliances

There’s a pattern in the last two years of router and firewall CVEs that’s worth naming directly: management interfaces get exposed to the internet because someone needed remote access once, and nobody ever locked it back down. Cisco’s Firewall Management Center, Citrix’s NetScaler, and now MikroTik’s RouterOS have all had auth-bypass chains discovered in their SSH or web management surfaces within the same twelve months. The lesson isn’t “patch faster,” though that helps. It’s that a management plane reachable from the open internet is a standing liability regardless of how quickly the vendor ships fixes, because the exploitation window for a zero-day is measured in days and your patch cycle probably isn’t.

If your team manages infrastructure for clients and this kind of exposure audit isn’t already part of your onboarding checklist, our security review process starts exactly there: what’s reachable from the internet that shouldn’t be, and what’s still running a version from before the last CVE. The same principle is why ransomware crews increasingly move faster once they’re past your perimeter: the exposure you leave open matters more than ever once the intrusion phase itself takes days instead of weeks.