Securify

Security researchers spent this week racing to warn the internet about “MikroTrick,” a chain of critical vulnerabilities in MikroTik’s RouterOS that lets attackers seize full administrative control of a router without ever supplying a valid password or key. MikroTik confirmed active exploitation and shipped emergency patches on September 5, but by then Poland’s national CSIRT, CERT Polska, had already traced live attacks back to at least September 2. The Shadowserver Foundation’s scans found more than 122,500 MikroTik devices with SSH exposed directly to the internet in a single 24-hour window — every one of them a potential target until patched.

That number matters more than it might sound. MikroTik routers are the backbone of a huge slice of the world’s small ISPs, WISPs, and budget-conscious enterprise networks, prized for being cheap, flexible, and powerful. That same ubiquity is exactly why they became infamous in 2021 as the engine behind Mēris, one of the most powerful DDoS botnets ever recorded, which used tens of thousands of compromised MikroTik devices to hammer Yandex, Cloudflare, and other major targets with record-breaking traffic. Any fresh, easily automated way to take over these boxes en masse is the kind of thing that keeps network defenders up at night, because it isn’t just about the router owner’s data — it’s about what the device can be conscripted to do to everyone else.

How the exploit chain works

MikroTrick isn’t a single bug; it’s a combination of flaws that add up to full pre-authentication compromise. MikroTik’s advisory and CERT Polska’s technical writeup identify three CVEs behind it:

CVE-2026-67276 (CVSS 9.2) is a flaw in RouterOS’s SSH public-key authentication. Normally, logging in with key-based auth requires possessing the private key that matches an account’s registered public key. Because RouterOS failed to fully validate the RSA public key material presented during authentication, an attacker who simply knew a valid username and the public modulus of that user’s key could craft a different key that RouterOS would accept — logging in without ever holding the real private key.

CVE-2026-86060 (CVSS 9.2) compounds that by allowing privilege escalation: usernames crafted with disallowed leading characters could trick RouterOS into granting the resulting session full administrative rights rather than restricted access.

CVE-2026-67277 (CVSS 8.8) is a separate issue in RouterOS’s bandwidth-test service, which could be reached without authentication to leak memory contents or trigger a denial-of-service condition.

Chained together, the first two flaws give an attacker outright administrative control of any device with SSH reachable from the public internet — no credentials, no phishing, no social engineering required. CERT Polska says it identified the bugs with help from OpenAI’s GPT-5.5-cyber and GPT-5.6-sol models as part of a government-agency AI collaboration program, which is itself a small but notable sign of how AI-assisted vulnerability hunting is becoming a routine part of national CSIRT work.

Once inside, attackers observed by researchers have been creating a persistence account named “ops” and modifying SSH keys, firewall rules, and proxy or tunnel settings to keep their access even after a reboot. A useful, slightly odd artifact of the exploit shows up in logs as failed login attempts from a username literally rendered as “-2” — not a real account, but a byproduct of the malformed authentication requests used to trigger the bug. Its presence in a router’s logs, or successful logins tied to that string, is a strong indicator of an attempted or successful compromise. Two source IP addresses — 82.192.72[.]4 and 103.102.31[.]18 — have been publicly linked to the observed attack traffic, though researchers caution that attribution to a specific group or nation-state actor has not been established.

Who’s affected

The vulnerable code spans both the legacy RouterOS 6.x branch and the current 7.x branch, meaning the exposure isn’t limited to old, unmaintained hardware. MikroTik’s own advisory strikes a somewhat reassuring tone, stating that “most configurations are not at risk” because the flaw specifically requires SSH to be reachable from an untrusted network — a device with SSH locked down to a LAN or VPN is not exposed. But that caveat is cold comfort given how many MikroTik boxes are deployed precisely as internet-facing edge routers for ISPs and small businesses, often managed remotely over SSH for convenience. Shadowserver’s 122,500-device count is a snapshot of internet-wide exposure, not a count of confirmed compromises, but it establishes the scale of the attack surface that existed the same week exploitation was already underway.

What to do now, and what to watch next

MikroTik has released fixes in RouterOS 6.49.21, 7.23.4, 7.24.2, and 7.25beta3, and administrators should update immediately rather than waiting for a routine maintenance window. Beyond patching, MikroTik and CERT Polska both recommend taking SSH, WWW, and the bandwidth-test tool off the public internet entirely and replacing exposed remote-management access with a VPN such as WireGuard. Post-patch, RouterOS will automatically flag devices it detects as compromised, but administrators should still manually check logs for the “-2” login artifact, look for an unexpected “ops” account, and audit SSH keys, firewall rules, and any proxy or tunnel configuration for changes they didn’t make. A device found to be compromised should be isolated from the network and, given how deeply an attacker with administrative access can bury persistence, a factory reset followed by a clean reconfiguration is the safer path rather than trying to manually undo the damage.

The bigger question hanging over this incident is what happens to the tens of thousands of routers that don’t get patched in time. Mēris showed how quickly a large population of exposed MikroTik devices can be turned into a weapon against third parties who have nothing to do with the original victims. Whether MikroTrick becomes a footnote or the seed of the next major botnet largely depends on how fast the long tail of ISPs and small businesses running these devices actually applies the update — and history suggests that tail can be very long indeed.

Sources: MikroTik Security Advisory (September 2026), CERT Polska, The Hacker News, Help Net Security, Security Affairs, and the Shadowserver Foundation.