9/5/2026 • Security

MikroTik's Quiet Patch Was Hiding an Actively Exploited SSH Flaw

MikroTik shipped a RouterOS update on 3 September saying "most configurations are not at risk" and withheld the details. Two days later CERT Polska confirmed attackers were already chaining two CVSS 9.2 SSH flaws to seize full control of routers with SSH open to the internet.

On 3 September 2026, MikroTik published a security notice that was deliberately vague. It said RouterOS had a vulnerability, that fixes were available in every release channel, that "most configurations are not at risk," and that details were being withheld to give people time to update. Within a day, a security researcher had reverse-engineered the patched binaries and worked out what was fixed. Within two, Poland's national CERT confirmed that attackers had been exploiting the flaws in the wild since at least 2 September, before the patch even existed.

If you have a MikroTik router anywhere in your business, and a lot of Australian small businesses do, whether they bought it themselves or an internet provider supplied it, this one is worth ten minutes of your day.

What happened, in plain English

CERT Polska, which coordinated the disclosure, found six vulnerabilities in RouterOS. Two of them, chained together, let an attacker take full administrative control of a router without any valid credentials, as long as the router's SSH service is reachable from the internet. CERT Polska gave the chain a name, MikroTrick, and has confirmed it is being used in real attacks.

The two flaws in the chain:

CVE-2026-67276 (CVSS 9.2) is an SSH public-key authentication bypass. RouterOS compared only part of a user's RSA key when checking a login, which meant an attacker who knew a target username and the public half of that user's key could forge a valid signature and open an SSH session as that user, with no private key at all. NVD rates it as requiring no privileges, but notes the attack complexity is high, because you need that public key material first.
CVE-2026-86060 (CVSS 9.2) is an argument-handling flaw in the SSH login path. A username beginning with a prohibited character (the researcher's write-up shows it was the literal string -2) was passed into a legacy login helper, which let the attacker rewrite the session's policy mask and escalate to full administrative rights. NVD classifies it as needing no prior privileges, with the caveat that the attacker has to be able to reach the SSH login helper.

The honest nuance here: neither flaw is "connect and you're root" on its own. The first gets you in as an existing user; the second turns any session into an administrator. Together, on a router with SSH exposed to the internet, they are exactly as bad as the headline suggests. CERT Polska has seen successful attacks that end with a new, highly privileged account called "ops" being created on the router.

The other four flaws are worth knowing about but are less immediately dangerous: CVE-2026-67277 (CVSS 8.8) lets an unauthenticated client abuse the bandwidth-test service to leak kernel memory or reboot the router; CVE-2026-67278 is a certificate-forgery weakness in X.509 handling; CVE-2026-67279 is another SSH state bug; and CVE-2026-67281 is an unauthenticated file-disclosure flaw in the WebFig web interface.

Fixes are available now in RouterOS 7.24.2 (stable), 7.23.4 and 6.49.21 (long-term), and 7.25beta3. CERT Polska has confirmed the patched releases stop the attacks it observed. As of the 4 September catalogue release, none of these CVEs is yet on CISA's Known Exploited Vulnerabilities list. The "actively exploited" claim rests on CERT Polska's direct observation, which is a credible, citable source, but do not be surprised if a KEV listing follows.

Why it matters: "most configurations are not at risk" is not "you're fine"

There is a real lesson in how this played out, and it is not just "patch your router."

MikroTik chose to ship fixes quietly and hold back the details. The intent was reasonable: give administrators a head start before telling attackers where to look. But as researcher Nick Pratley put it after diffing the old and new binaries, if you ship fixed software to the whole world, the diff is the disclosure. Attackers with the skills to do that analysis do not need the vendor's write-up. Meanwhile, the admins the silence was meant to protect read "most configurations are not at risk" and, understandably, put it on next month's list.

The result is the worst of both worlds: the people who could exploit it knew quickly, and the people who needed to patch did not know how urgent it was. If you take one thing from this post, it is that a vague vendor notice deserves the same urgency as a loud one, especially for a device that sits on your internet edge.

The second lesson is that the danger here is entirely about exposure. Every one of the serious flaws needs the attacker to reach SSH, WebFig or the bandwidth-test service. A MikroTik router that only accepts management connections from inside your office was never in the firing line. The ones being hijacked right now are the ones with port 22 open to the world, often because someone enabled remote access years ago "just for a bit" and never turned it off. We have written before about what happens to forgotten gear, and this is the same story with a different logo.

The honest bit

No vendor is immune, including the ones we like. We sell Cisco and Meraki equipment, and Cisco has had its own run of critical advisories this year, several of which we have covered in this series, including the RV router flaws that will never be patched. MikroTik makes genuinely capable, good-value hardware and a lot of skilled Australian network people swear by it. And to be fair, MikroTik did something interesting here: the patched firmware now scans the configuration at boot for known signs of compromise, disables anything suspicious, and puts the device into a "Flagged" state that blocks creating new scheduler tasks, proxies and tunnels until an administrator has had a look. That is a thoughtful touch that more vendors should copy, though CERT Polska is careful to note that the absence of a flag is not proof a device is clean.

One genuine difference, offered as advice rather than a pitch: cloud-managed platforms push security fixes to devices automatically and tend not to have a management port sitting on the public internet in the first place, because management happens through the cloud dashboard. That removes the two things that made this attack work, the exposure and the delay. We have written about why that model keeps improving after you buy it. It is not the only way to be safe, but it does take the "did anyone remember to update the router?" question off the table.

What we'd suggest you actually do

Find out whether you have one. MikroTik routers turn up under many names: hAP, RB-series, CCR, CRS switches, and the Cloud Hosted Router virtual appliance. Check your comms cupboard and ask your provider if they supplied the router. If you are not sure, ask someone who can look.
Update today. Use the router's built-in update menu to move to 7.24.2, 7.23.4 or 6.49.21, whichever channel you are on. This is not a "schedule it for the next maintenance window" update.
Check for signs of a break-in, even after patching. Look in the log for the message about the device being Flagged, run /system/device-mode/print, and go through the user list, scripts, scheduler tasks, proxy settings and tunnels for anything you do not recognise. A user called ops that you did not create is a red flag. CERT Polska's advisory lists the exact log lines the attackers leave behind.
If you cannot patch right now, close the doors. Disable SSH, the web interface (WWW and WWW-SSL) and the bandwidth-test service on the internet-facing side, or restrict them to your internal network and trusted addresses. This is the single most effective protection, and it should stay in place after you patch.
If the router is Flagged or you find something odd, assume it is compromised. Isolate it, save the logs and config for evidence, reset it to factory defaults, rebuild it from a known-good configuration rather than restoring a full backup, and change every password, key and shared secret that lived on it. Report it to the ACSC if your business handles anything sensitive.
Do the basics everywhere else. No default or shared admin passwords, no management interfaces on the public internet, and a way of hearing about updates that does not depend on someone reading a vendor forum. If you want that last part done for you, that is what this series is.

The friendly takeaway

This is not "MikroTik bad." It is a reminder that the quietest patch of the month can be the most urgent one, and that the real vulnerability in most small businesses is not a CVE number but an SSH port that has been open to the internet since 2019. Patch, check for the ops user, close the management ports, and you are ahead of the attackers who started on this before the fix existed.

As always, this post is part of us keeping watch so you don't have to. If you would like a second pair of eyes over what is reachable from the internet at your place, whose gear it is, and whether it is still supported, get in touch. No obligation, no hard sell. Sometimes a ten-minute look is all it takes.

What happened, in plain English

Why it matters: "most configurations are not at risk" is not "you're fine"

The honest bit

What we'd suggest you actually do

The friendly takeaway

References