MikroTik's SSH router bug shows why forgotten hardware is the internet's biggest liability

Three weeks after MikroTik shipped patches for two critical SSH vulnerabilities, more than 122,000 of its routers were still reachable from the open internet with the flaw unpatched. That gap is not a story about a hard bug to fix — MikroTik patched it within days of disclosure. It is a story about who actually owns the job of updating a router once it is bolted to a wall and forgotten.

MikroTik's RouterOS sits in a strange blind spot in the hardware world. It is not a consumer product that auto-updates in the background like a phone or a laptop. It is not enterprise gear with a dedicated network operations team watching a dashboard. It is the default choice for ISPs building last-mile networks, small businesses running their own edge routers, and hobbyists who like having full control over their network — which means nobody in particular is responsible for patching it, and everybody assumes someone else is.

How the exploit chain works

Researchers have named the attack chain "MikroTrick," and it combines two separate bugs into a path to full administrative control without any valid credentials. The first, CVE-2026-67276 (CVSS 9.2), is an authentication bypass in RouterOS's SSH implementation: the system only compared the public modulus of a user's RSA key, not the entire key, when verifying a login attempt. An attacker who already knew a username and its public modulus — both of which can often be harvested from prior scans or leaked configuration backups — could craft a different key that satisfied the flawed check and log in without ever possessing the real private key.

The second bug, CVE-2026-86060 (also CVSS 9.2), is a privilege escalation flaw triggered by SSH usernames that begin with a disallowed character. RouterOS mishandled the malformed username in a way that returned a session with full administrative privileges instead of rejecting the connection. Chained together, the two bugs let an attacker with internet access to a router's SSH port go from zero credentials to root-equivalent control in a single connection attempt. A third, lower-severity flaw (CVE-2026-67277, CVSS 8.8) in the bandwidth-test service adds memory disclosure and denial-of-service on top.

The scale problem

Security researchers observed exploitation attempts as early as September 2nd — three days before MikroTik's public advisory on September 5th. Scans conducted in the days following the disclosure found roughly 122,500 MikroTik devices with SSH exposed to the public internet in a single 24-hour window. Not all of those were running vulnerable firmware, but the number illustrates how many of these devices are deployed with management interfaces facing the open internet at all, which is itself the more fundamental problem.

Patches exist in RouterOS 7.25 beta 3, 7.24.2, 7.23.4, and 6.49.21, covering both the current stable branch and MikroTik's long-term-support branch. For an ISP or business that treats its router as invisible infrastructure — something installed once and never revisited — discovering that an update is even available requires someone to actively check, since RouterOS does not push updates automatically by default.

A pattern that keeps repeating

This is not a new failure mode. Mirai and its descendants turned millions of unmanaged IoT devices and routers into botnets for exactly this reason: the hardware works fine for years without anyone logging in, so nobody logs in to patch it either. MikroTik routers are a particularly attractive target compared to cheap consumer routers because they are more powerful, often sit at network edges with real bandwidth, and are frequently configured by people technical enough to expose SSH to the internet for remote management — without layering on the access controls that would prevent exactly this kind of attack.

The compromise indicator researchers are circulating is worth noting for anyone running MikroTik gear: a suspicious SSH user account with a name ending in "-2" is one signature CERT Polska and other responders have observed left behind by the exploit chain, since the malformed-username bug tends to create oddly named accounts as a side effect.

What to actually do about it

If you operate MikroTik hardware, the fix priorities are straightforward and don't require waiting for a perfect understanding of the exploit chain. Update to a patched RouterOS version first — this closes both critical bugs at once. Second, audit whether SSH, WWW, WWW-SSL, and the bandwidth-test service actually need to be reachable from the public internet; in the large majority of deployments they do not, and restricting them to a management VLAN or VPN removes the exposure entirely regardless of what future bugs get found. Third, check for the "-2" suffixed accounts and any unrecognized SSH keys as a quick compromise check.

The broader lesson generalizes past MikroTik. Any device category that sits between "consumer product with forced updates" and "enterprise gear with a paid support contract" tends to accumulate exactly this kind of unpatched population — SOHO routers, network-attached storage boxes, industrial control gateways, and increasingly, self-hosted smart home hubs. The fix isn't just better patches. It's deciding, explicitly, who owns the update cycle for hardware that nobody wants to think about once it's plugged in.