MikroTik routers face active exploits despite quick patches, prompting urgent incident response

Attackers are actively exploiting critical vulnerabilities in MikroTik RouterOS devices globally, with new features supporting simultaneous attack detection and response now recommended for network administrators.

Administrators of internet-facing MikroTik routers are being urged to handle this as a live security incident rather than a routine software update after CERT Polska confirmed that attackers have been taking over RouterOS devices with publicly reachable SSH since at least 2 September 2026. Latvia’s national CERT has separately said it is also seeing intensified attempts against exposed systems, underscoring that the activity is not confined to one country or one set of victims. (cert.pl)

The immediate danger comes from a two-bug chain that CERT Polska has named MikroTrick. One flaw, CVE-2026-67276, stems from incomplete RSA key checking in the SSH login process: RouterOS compared the key type and modulus but not the exponent, making it possible to impersonate an authorised user if the attacker knows the public modulus. The second, CVE-2026-86060, is an SSH privilege-escalation bug triggered by a crafted username beginning with a forbidden character, allowing the session’s policy mask to be altered and elevated to full administrative rights. CERT Polska disclosed four other issues in the same research set, affecting bandwidth-test, X.509 certificate handling, a separate SSH rekey path and the WebFig interface, which means the patching case extends beyond the takeover chain alone. (cert.pl)

MikroTik published fixed builds on 3 September, but its public notice gave only a brief warning that it had found “a security vulnerability” and that “most configurations are not at risk”. The repaired versions are 6.49.21, 7.23.4, 7.24.2 and 7.25 beta 3. Operators on the long-term 7.x branch have already been pointed towards 7.23.5 as well, because MikroTik’s download notes say that release keeps the security fix while correcting an urgent IPv6 DHCP problem introduced in 7.23.4. The Hacker News also noted that MikroTik’s default firewall rules on typical home devices block direct access to management ports if those defaults are still in place, which helps explain the vendor’s view that the highest risk lies with deliberately exposed administrative services. (mikrotik.com)

What makes this more than a patch notice is the post-upgrade inspection now required. CERT Polska says the new RouterOS builds include a “Flagged” mechanism that scans startup configuration for known signs of unauthorised changes, disables recognised suspicious entries and writes a critical log message. Both CERT Polska and MikroTik stress that a clean result is not proof of safety. Administrators are being told to review logs, check /system/device-mode/print, and inspect users, scripts, scheduler tasks, proxy settings, tunnels and other configuration elements for changes with no legitimate origin. (cert.pl)

The forensic markers published so far are unusually specific. CERT Polska says the attack chain has left log entries such as login failure for user -2 from <ip> via ssh and user <name> added by ssh:-2@<ip>, while the presence of a highly privileged account called “ops” is another compromise indicator. The available reporting still gives no victim count and no firm attribution, but the infrastructure details are beginning to emerge. Security Affairs, citing Costin Raiu’s analysis, said the main source of successful intrusions was 82.192.72.4, described as a Leaseweb IP hosting a BusyBox MIPS binary together with ftpsrv.py, launch.sh and serve.py; attempts were also linked to 103.102.31.18. CERT.LV added an important caveat: the absence of these artefacts does not rule out unauthorised access. (cert.pl)

The operational advice has therefore moved into incident-response territory. If an upgrade cannot be applied immediately, CERT recommends disabling or tightly restricting SSH, WWW, WWW-SSL and bandwidth-test so that only trusted management networks can reach them. Because the wider disclosure includes X.509 and SSH-client-side weaknesses, unpatched devices should also avoid outbound TLS sessions and use of RouterOS’s built-in SSH clients across untrusted networks. Where compromise is suspected, the guidance is to isolate the router, preserve logs and configuration, reset it, rebuild from a known-good configuration rather than a possibly tainted full backup, and rotate passwords, SSH keys and other secrets that were present on the device. (thehackernews.com)

There is still some disagreement over how to describe the timing. Costin Raiu and other secondary reports have framed the campaign as a zero-day because successful exploitation was observed from 2 September and MikroTik’s fixed releases were published on 3 September. However, The Hacker News argued on 6 September that those dates alone do not prove a public fix was unavailable before the attacks began, so the label remains unconfirmed. What is clear is that MikroTik deliberately withheld technical detail “to give time to update your systems”, yet patched binaries were public, and Anthony Bahn reported that independent researcher Nick Pratley had already diffed versions 7.23.3 and 7.23.4 and published his analysis by 4 September, a day before CERT Polska issued the full advisory and CVE records. (securityaffairs.com)

For operators, the practical conclusion is narrow and urgent. Home users who never exposed management services may face lower immediate risk, but this incident is aimed squarely at the many small providers, branch offices and technical teams that leave RouterOS administration reachable from outside. Even organisations that did not expose SSH should not dismiss the update, because CERT Polska’s six disclosed flaws also touch bandwidth-test, WebFig and certificate validation. In other words, patching is necessary, but it is only the start; the real question is whether an attacker reached the router before the upgrade did. (mikrotik.com)