MikroTrick: MikroTik RouterOS SSH Takeovers in the Wild

MikroTik RouterOS spent the first week of September 2026 in the middle of a fast edge-device incident. CERT Polska coordinated disclosure of six RouterOS bugs and confirmed that two of them are already chained in the wild into a full, unauthenticated takeover whenever SSH is reachable from the internet.

They named that chain MikroTrick. If you run MikroTik gear in a homelab, as ISP CPE, as a branch firewall, or as CHR on a VPS, patch first and hunt second.

What changed, in order

MikroTik published fixed RouterOS builds on 3 September 2026. CERT Polska published technical context and CVE assignments on 5 September. Exploitation evidence goes back to at least 2 September, a day before the public fixes. Several write-ups treat the campaign as having zero-day characteristics for that reason: attackers were already succeeding while fleets were still unpatched.

MikroTik also did something unusual. For the first time it pushed a mobile-app notification telling users to update. Treat that as a severity signal, not marketing fluff.

The MikroTrick chain without the exploit recipe

CERT Polska's public description is enough for defenders. I am not reproducing a PoC here.

CVE-2026-67276 (CVSS 9.2) is an SSH authentication bypass. RouterOS did not fully validate the RSA public key used during SSH auth. It failed to compare the entire key material assigned to the user. An attacker who knew a username and enough public key material could authenticate without the legitimate private key.

CVE-2026-86060 (CVSS 9.2) is SSH privilege escalation. Crafted usernames in the login path could yield a session with full administrative RouterOS privileges.

Chained together the path is simple to state and ugly in production: internet-reachable SSH, authenticated session, admin-equivalent control. No valid password. No user click.

CVE-2026-67277 (CVSS 8.8) hits the bandwidth-test service and can leak kernel memory or remotely crash the device. It is not the primary MikroTrick takeover path, but it is another reason to stop exposing management-adjacent services to the world. CERT also reported additional issues around SSH client and server paths, X.509 handling, and WebFig. Treat the September update as a bundle.

If you want the broader framing of how vulnerabilities, IoCs, and mitigations fit together as an operator decision loop, I wrote that up in [Vulnerabilities, IoCs, and Mitigations](/research/vulnerabilities-iocs-mitigations).

Who is actually exposed

MikroTik's bulletin is careful. Default configurations that keep SSH off the public internet sit in a much better place. The acute risk is devices where someone opened management ports, especially SSH, to untrusted networks "just for a minute."

That pattern shows up constantly: small-office routers with Winbox or SSH forwarded, ISP and WISP CPE fleets with remote management habits, lab routers on public VPS images, and "I'll put WireGuard in front later" setups that never got later. Scanning around the disclosure window showed well over 100,000 MikroTik hosts with SSH visible from the internet. Not all share the same risk class, but the surface was large enough that opportunistic scanning was inevitable.

Fixed versions

Install one of the fixed trains listed by MikroTik and CERT Polska:

1. 7.25beta3
2. 7.24.2
3. 7.23.4
4. 6.49.21

Use System, Packages, Check for updates, or your normal fleet pipeline. Do not invent "close enough" builds. After upgrade, move straight into compromise checks. Patching closes the hole. It does not undo a prior takeover.

Bridge controls if you cannot patch in the next hour

These reduce blast radius. They do not replace the update.

Remove public exposure of SSH, WWW, WWW-SSL, and bandwidth-test. Allow management only from a jump host, an out-of-band network, or a strong VPN. MikroTik explicitly suggests WireGuard-style access and no open management ports. Until patched, avoid using the device's built-in SSH and TLS client features toward untrusted peers, including /system ssh and /system ssh-exec. Inventory every RouterOS instance: branches, backup routers, forgotten conference-room APs that still run RouterOS, and virtual CHR boxes.

Hunt after every upgrade

Patched builds include a Flagged mechanism. On startup, RouterOS can scan for known unauthorized-change fingerprints, disable some suspicious entries, write a critical log line, and set a warning marker.

CERT Polska's critical nuance still applies: absence of Flagged is not proof of cleanliness. Attackers change tooling. The marker catches selected fingerprints, not every post-exploitation state.

Run at least:

/system/device-mode/print
/log print where message~"-2"
/user print where name="ops"
/user print
/system script print
/system scheduler print
/ip service print

Also review proxies, tunnels, firewall rules, and any fetch or import automation you did not create.

CERT associated observed attacks with log patterns like:

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

An additional indicator is a highly privileged local user named ops. Observed attacker infrastructure called out in the 5 September advisory included 82.192.72.4 for successful attacks and ops creation since at least 2 September, plus 103.102.31.18 for exploitation attempts. Treat those IPs as investigation pivots, not as an exclusive list of evil. Infrastructure rotates.

For the incident-response side of "what next after the IoC hits," see [Incident Response and Vulnerability Management](/research/incident-response-vulnerability-management).

If Flagged, or anything looks wrong

Assume takeover until you prove otherwise. Isolate the device from production traffic where you can. Preserve logs and configuration before you wipe, using a trusted export procedure. Report to your national CSIRT if you are in scope. Factory-reset, then rebuild from a known-good configuration. Do not blindly restore a full backup taken from a possibly poisoned device. Rotate passwords, SSH keys, VPN PSKs, RADIUS secrets, API tokens, and certificates that lived on that box. Do not clear the Flagged marker before evidence handling is finished.

Edge routers are trust anchors. A quiet admin account plus a tunnel implant or a scheduled script can outlive a casual "I upgraded, looks fine" moment.

Why this case travels beyond MikroTik

Management-plane exposure is still the cheapest critical finding. The crypto and policy bugs matter, but the operational failure mode is familiar: SSH on 0.0.0.0/0.

Vendor silence windows and patch diffs cut both ways. MikroTik initially withheld details to buy patch time. Once packages were public, the community could reverse parts of the fix. "No blog post yet" does not mean attackers are waiting politely.

CERT Polska also stated that the research used GPT-5.5-cyber and GPT-5.6-sol inside a supervised agentic lab with real RouterOS instances, negative controls, and human verification. The industry takeaway is not that models find CVEs by magic. Well-instrumented labs plus model-assisted exploration can accelerate protocol and binary hypothesis testing when humans still own scope, safety, and confirmation.

If you are mapping this kind of edge compromise into Security+ style control language, [Security Controls, CIA, and AAA](/research/security-controls-cia-aaa) is a useful companion.

Practical close

Inventory every RouterOS device, including CHR, backups, and lab. Upgrade to 7.24.2, 7.23.4, 6.49.21, or 7.25beta3 as appropriate. Confirm SSH, Winbox, and WWW are not exposed to the internet. Check /system/device-mode/print for Flagged. Hunt logs for -2 and ssh:-2@, and hunt users for ops. Review scripts, scheduler, tunnels, and proxies. If anything is suspicious: isolate, preserve evidence, reset, rebuild, rotate secrets.

Primary sources: the [CERT Polska advisory](https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/) and the [MikroTik September 2026 bulletin](https://mikrotik.com/supportsec/september-2026-vulnerability).

Bottom line: if RouterOS SSH ever faced the internet, patch now and treat post-upgrade hygiene as part of the incident, not an optional appendix. MikroTrick is already past the theoretical CVE stage.