MikroTik Routers Hijacked Over Exposed SSH: What the MikroTrick Flaw Means and How to Harden Yours

On 5 September 2026, Poland’s national CERT confirmed something that should focus the mind of anyone running a router at the edge of a network: attackers are taking full administrative control of internet-exposed MikroTik devices without any username, password or private key. The chain has a name now, MikroTrick, and it is being used in the wild.

This is a MikroTik story on the surface, but it is really a story about every device that sits between a network and the public internet. Below we cover exactly what CERT Polska found and what to do about it, then step back through more than a decade of router and edge-device attacks that put this incident in context, and finish with the part that matters most for anyone running industrial or business-grade kit: what to lock down on any deployment, whether the box on the wall says MikroTik, DrayTek, Teltonika, Cisco or Peplink.

What CERT Polska found

CERT Polska disclosed six vulnerabilities in MikroTik’s RouterOS, two of them critical, after its own research team found the flaws and coordinated their disclosure. The dangerous part is not any single bug but a combination of two of them, which the team named MikroTrick to make the chain easier to talk about and hunt for. Together they let an attacker reach full administrative control of a device whose SSH service is reachable from a public network, with no valid credentials required.

The anchor of the chain is CVE-2026-67276, an SSH authentication bypass rated CVSS 9.2. The mechanism is a neat illustration of how a small logic error becomes a total compromise. When RouterOS matched an incoming SSH key against an authorised user key, it compared the key type and the modulus but left out the exponent. Because the signature check then used the client-supplied key, an attacker who already knows the modulus of an authorised RSA key can present a crafted key with an exponent of one, forge a valid-looking signature, and open a command channel as that user, without ever holding the private key. That authentication bypass is then paired with a privilege-escalation weakness (reported as CVE-2026-86060) to reach full control. Reporting has not been perfectly consistent on exactly which second flaw completes the chain, but the practical outcome is not in dispute: unauthenticated admin over exposed SSH.

The wider disclosure is worth knowing about too, because the interim advice depends on it. The other issues include a bandwidth-test session accepted before its primary session has authenticated, an X.509 validation flaw that lets an attacker who can redirect a RouterOS outbound TLS connection impersonate a trusted server, and an SSH flaw where the connection protocol proceeds after a client-requested rekey even though authentication never happened. In other words, it is not only inbound SSH you need to think about on an unpatched device.

MikroTik shipped fixes on 3 September across every release channel, and CERT confirms the patched builds stop the observed attacks. The vendor even pushed its first-ever notification to users of the MikroTik mobile app, which tells you how seriously it is being taken.

One wrinkle for anyone on the long-term branch: 7.23.5 was issued to fix an IPv6 DHCP regression introduced in 7.23.4, while keeping the security fix intact. So on long-term, go to 7.23.5 rather than stopping at 7.23.4. Always pull firmware from MikroTik’s official download page rather than a mirror.

Can’t patch this minute?

Until you can update, CERT’s guidance is to turn off the exposed services or restrict them to trusted management networks only, with particular attention to SSH, the WWW and WWW-SSL web interfaces, and bandwidth-test. Because the broader set of flaws includes client-side and TLS weaknesses, an unpatched device should also avoid initiating outbound TLS connections and should not use RouterOS’s built-in SSH clients across untrusted networks. These are stopgaps. They do not replace the update.

Signs your MikroTik may already be compromised

The patched releases add a self-check: at startup RouterOS scans the configuration for known traces of tampering, disables the entries it recognises, writes a critical log message and sets a “Flagged” marker. Useful, but read the small print. It only catches selected artefacts, so the absence of a flag is not proof the device is clean.

After updating, inspect the device properly. Check the logs, run /system/device-mode/print to review that status, and look through the configuration for anything you did not put there: unknown users, unfamiliar scripts, scheduler entries, proxy settings and tunnels. CERT has published specific indicators from the observed campaign:

• Creation of a highly privileged account named ops.
• Account-creation log entries containing ssh:-2@, sometimes surfacing as an SSH user called -2.
• Activity from the source addresses 82.192.72.4 (linked to the ops account creation) and 103.102.31.18 (used in exploitation attempts).

The presence of any of these means you should investigate immediately. Their absence, again, does not clear the device.

This is not MikroTik’s first rodeo

It is tempting to file MikroTrick under “one vendor’s bad week”. It is more useful to see it as the latest entry in a very long list. Edge routers have been a favourite target for both criminal botnets and state actors for years, and MikroTik in particular keeps appearing in the story.

Go back to 2018 and VPNFilter, malware attributed to a Russian state group, infected well over half a million routers and network storage devices worldwide, MikroTik among them, alongside Linksys, Netgear, TP-Link and QNAP. It could sniff traffic, survive a reboot and, if instructed, brick the device. The same year, a RouterOS flaw in the Winbox service (CVE-2018-14847) let attackers read the credential database, and it was mass-exploited to hijack hundreds of thousands of MikroTik routers, in many cases to inject cryptomining scripts into the web traffic passing through them.

By 2021 the unpatched long tail of those devices helped build Meris, a botnet of roughly a quarter of a million mostly MikroTik routers that launched some of the largest application-layer denial-of-service attacks recorded at the time. The pattern is the same each time: a known flaw, a patch that many owners never applied, and a huge population of forgotten internet-facing boxes waiting to be conscripted.

It is not just MikroTik, and it is not just criminals chasing crypto. A few landmarks from the last couple of years alone:

• Cisco IOS XE (2023): a web UI flaw (CVE-2023-20198) was exploited at scale within days, with implants dropped on tens of thousands of enterprise devices.
• Volt Typhoon (2024): US authorities ran a court-authorised operation to clear China-linked malware off hundreds of small-office and home routers, many of them end-of-life models, that were being used to quietly pre-position inside critical infrastructure.
• APT28 / EdgeRouter (2024): a separate operation disrupted a botnet of Ubiquiti routers used by a Russian military intelligence group.
• Salt Typhoon (2024 onward): China-linked intrusions into telecoms networks leaned heavily on compromised edge and routing equipment.

And DrayTek, a brand as common as MikroTik in UK small business and prosumer setups, has had a torrid run of its own. In October 2024 Forescout published DRAY:BREAK, fourteen vulnerabilities across Vigor routers, including a maximum-severity remote code execution bug in the web interface and an OS command execution flaw, with something like 700,000 devices exposed. Researchers subsequently detailed a coordinated ransomware campaign that had quietly hit tens of thousands of Vigor devices using a suspected zero-day, tied to real-world incidents. Older DrayTek flaws from 2020 and 2021 were still being actively exploited in 2025, coinciding with waves of devices spontaneously rebooting, and a fresh unauthenticated RCE (CVE-2025-10547) landed in late 2025 affecting dozens of Vigor models. National agencies have repeatedly warned that this class of device, routers and IoT gear at the network edge, is exactly what large botnet operations are built from.

Industrial and top-end routers: harder targets, same fundamentals

A fair question at this point: MikroTik and DrayTek are inexpensive, widely deployed kit, so is the answer simply to buy industrial-grade or enterprise routers instead? Higher-end hardware genuinely does help, better security engineering, longer support commitments, signed firmware, cleaner update tooling, but it is a mistake to read “industrial” as “immune”.

The industrial and cellular router market is broad. At the value and prosumer end sit MikroTik and DrayTek. Then there is a large middle-to-upper tier built specifically for demanding deployments: Teltonika’s RUT and RUTX ranges, Robustel, InHand Networks, Advantech, Moxa, Milesight and Digi are all common in industrial IoT and OT settings. At the top end you find Cisco’s IR industrial routers, Peplink, Sierra Wireless AirLink (now under Semtech) and Cradlepoint (Ericsson), often carrying multi-carrier cellular, SD-WAN and management platforms designed for fleets of thousands.

None of that changes the underlying maths. Vulnerabilities have been disclosed across effectively every vendor in that list at one time or another, industrial-grade names included, and researchers have flagged serious flaws in dedicated industrial routers such as Helmholz units. A signed, well-maintained firmware image still has to be applied. A hardened default still gets undone the moment someone ticks “enable remote access” and forwards a port to get a site online quickly. The failure that MikroTrick exploits, a management service exposed to the whole internet, is a configuration and process problem far more than it is a brand problem. Spending more on the hardware raises the floor. It does not remove the need to run the thing properly.

So the useful takeaway is not a shopping list. It is that the same handful of disciplines protect a 40-pound MikroTik and a several-thousand-pound Cisco industrial router alike.

What to ensure for a secure installation

Here is the core checklist we would apply to any router deployment, from a single site to a managed fleet. It is deliberately vendor-neutral, because the fundamentals do not change between RouterOS, DrayOS, RutOS, IOS or anything else.

• Never expose management to the public internet. SSH, the web UI, Winbox, the API and any vendor cloud agent should be bound to the LAN or a management interface only. The single most common thread through every incident above is a management service reachable from anywhere.
• Put remote administration behind a VPN. Use WireGuard, IPsec or the device’s own secure tunnel and administer over that, rather than opening ports. Where a VPN genuinely is not possible, restrict the service by source IP with a strict allow-list, and treat that as a temporary compromise, not a design.
• Patch on a schedule, and subscribe to advisories. Know your firmware version, track vendor security bulletins, and act on critical ones as incidents. Note end-of-life dates, an unsupported device is a liability the moment the next flaw appears.
• Kill default and weak credentials. Unique strong passwords, no shared logins, remove unused accounts, and use key-based authentication with multi-factor where the platform supports it.
• Disable everything you are not using. Bandwidth-test, legacy management protocols, unused WAN services and cloud management you do not rely on all widen the attack surface for no benefit.
• Segment the network. Keep router management on its own VLAN, separate OT from IT, and apply least privilege so a compromised edge device cannot pivot freely into everything behind it.
• Log off the box and watch for change. Ship logs to external syslog or a SIEM, and alert on new admin accounts and configuration changes. On-device logs are the first thing an attacker clears.
• Keep an inventory and check your own exposure. Maintain a record of every device, model, firmware level and internet exposure, and periodically look yourself up on Shodan or Censys to see what the world can see.
• Protect configuration integrity. Hold a known-good baseline config, and after any suspected compromise rebuild from that baseline rather than restoring a backup that may already carry the attacker’s changes.

The takeaway

MikroTrick is serious, and if you run exposed MikroTik kit it deserves an immediate response. But the more durable lesson is the one it shares with VPNFilter, Meris, the DrayTek campaigns and every state-run edge-router operation of the last few years. The router is not a passive appliance. It is an internet-facing computer running privileged software, and it needs the same patching discipline, the same access control and the same monitoring you would give any other critical system. Buy good hardware by all means. Then install it as if someone is already scanning for it, because they are.