CVE-2026-67279 + CVE-2026-86060: How 'MikroTrick' Took Root on 122,500 Routers Without a Password

On September 2, 2026 — one day before MikroTik shipped a fix — researchers started seeing exploitation attempts against internet-exposed RouterOS devices using a two-bug chain now tracked publicly as CVE-2026-67279 and CVE-2026-86060. CISA added the first to its Known Exploited Vulnerabilities catalog on September 25. By the time defenders caught up, the chain — nicknamed "MikroTrick" — had been used against an estimated 122,500 internet-facing routers to create privileged accounts and exfiltrate device configuration, no password or SSH key required.

What makes this one worth a closer look isn't the scale, although that's bad enough for a single vendor's SSH daemon. It's that neither bug in the chain is, on its own, the kind of thing a code review usually flags as catastrophic. One is a protocol state-machine edge case. The other is a classic argument-injection bug that's been a known class since the 1990s. Neither looks like "unauthenticated root" in isolation. Chained, that's exactly what they are.

Bug one: trusting a rekey too much

SSH connections periodically rekey — renegotiate session keys partway through a long-lived connection, without tearing down and restarting the whole handshake. It's a normal, client-initiable operation, and it happens below the authentication layer: a rekey refreshes the transport-layer encryption, it doesn't imply anything about who (if anyone) has logged in.

CVE-2026-67279 is a bug in how RouterOS's SSH server tracked state across that rekey. After a client-initiated rekey, the server incorrectly transitioned into the post-authentication session phase — the phase where it accepts channel-open and exec requests — even when the client had never actually completed user authentication. In other words: skip the login, send a rekey, and the server behaves as if you're already in.

That gets an unauthenticated client to the point of opening a session channel and issuing commands. On its own, that's already a serious bug. But RouterOS still runs those commands through its normal login/privilege path — which is where the second bug comes in.

Bug two: a username that isn't a username

CVE-2026-86060 lives in how RouterOS's SSH daemon hands off to its login helper program. When a session is established, the daemon invokes the login program and passes the username and requested privilege level as command-line arguments. The login program doesn't validate the username string before treating it as an argument — and most CLI argument parsers share a well-known quirk: a value that starts with a hyphen is interpreted as a flag, not as data.

So a "username" like --group=full or an equivalent option string isn't rejected as an invalid login — it's parsed as a command-line flag to the login helper itself, letting the caller set the privilege level the helper assigns rather than accepting whatever the real account would be entitled to. This is the same bug family as rm -rf --no-preserve-root / getting handed a filename that starts with - and chainsaws through options instead of files, or git historically needing -- to stop a crafted branch name from being parsed as a flag. It's older than most of the engineers who keep rediscovering it.

The chain

Put the two together and the attack path is almost mechanical:

1. Open a TCP connection to the exposed SSH port — no credentials needed.
2. Trigger a client-initiated rekey before completing authentication (CVE-2026-67279), landing in the post-auth session state anyway.
3. Open a channel and issue a login/exec request with a privilege-level argument crafted to be parsed as a flag by the login helper (CVE-2026-86060).
4. Walk away with an administrative account on the device — no password, no key, no prior access.

From there, the observed in-the-wild activity is unglamorous and effective: create a new privileged user for persistence, pull the device configuration (which often contains other credentials and network topology), and move on to the next exposed target. No malware, no exotic payload — just two logic bugs doing exactly what they were (mis)coded to do.

Affected versions

Branch	Vulnerable	First patch	Status
6.x Long-term	before 6.49.21	6.49.21	Fixed
7.x Long-term	before 7.23.4	7.23.4	Initial fix incomplete — update again
7.x Stable	before 7.24.2	7.24.2	Initial fix incomplete — update again

If SSH management is reachable from the internet on any of these branches, treat it as compromised-until-verified, not just unpatched-until-verified — the exploitation window opened before the first patch did.

Why this kept working at scale

122,500 exposed devices is a number that says something about the install base, not just the bug. RouterOS ships on home-office and small-business routers that are frequently deployed once and never touched again — no centralized patch management, no fleet-wide SSH exposure audit, often no one whose job it is to notice a CVE number scroll by. Management-plane services like SSH get left reachable from the WAN because turning them off would mean a site visit, and a site visit costs more than the perceived risk of leaving port 22 open.

That's the actual lesson here, more than the specific state-machine bug: a management interface exposed to the internet is a standing bet that every bug in that interface, forever, will be either non-critical or caught before exploitation. This CVE is what happens when that bet loses. It's not a new argument for restricting management-plane access to a VPN or an allowlisted jump host — that argument has existed for twenty years — but it's a fresh, very concrete illustration of the cost of not acting on it.

What this means for how we teach it

This chain is a genuinely good lab exercise precisely because neither half of it reads as scary in a code snippet. A protocol state-machine bug in a rekey handler looks like a corner case an auditor might wave through — "that path requires the client to do something unusual, low priority." An unvalidated username passed as a CLI argument looks like exactly the kind of thing every security-basics course already covers, which makes it easy to assume it's been found already. The actual skill this CVE exercises is refusing to dismiss a bug as low-impact just because exploiting it alone gets you nowhere — and specifically, building the habit of asking "what does the next layer do with what I just got?" every time a vulnerability search turns up something that's merely "interesting."

It's also a clean, hands-on demonstration of why argument injection deserves to be taught as its own bug class rather than a footnote under "input validation." Students who've only ever seen it in a toy ls $USER_INPUT example tend to underrate how often real production code still hands untrusted strings straight to a program's argv — and a lab built around reconstructing MikroTrick step by step, from rekey timing to the exact flag that gets the login helper to misbehave, teaches that lesson in a way a slide describing CVE-2026-86060 in the abstract never will.

The takeaway

MikroTrick isn't a story about MikroTik being careless — it's a story about how two individually modest bugs, in two different subsystems written at two different times, combined into unauthenticated administrative access on a router that was never supposed to let an unauthenticated client past the login prompt at all. If you run RouterOS with SSH reachable from the internet, the fix is simple and overdue regardless of CVE numbers: get management access behind a VPN or allowlist, confirm you're on 6.49.21 / 7.23.4-plus-the-follow-up / 7.24.2-plus-the-follow-up, and audit for the privileged accounts this chain is known to plant before you assume the patch alone cleaned things up.