The Patch Shipped Thursday. The Attackers Showed Up Wednesday.

Attackers were logging into MikroTik routers on September 2. MikroTik shipped the fix on September 3. That gap is the whole story of this incident, and it's the story of edge devices in general. Everything below is detail.

What happened

Costin Raiu, who ran Kaspersky's GReAT team for years and knows what real exploitation looks like, published a writeup on September 6. Short version: someone was hitting internet-facing MikroTik routers over SSH, getting in with no valid credentials, and creating a new admin user called "ops." He saw exploitation roughly 24 hours before MikroTik released fixed versions.

CERT Polska put out its advisory on September 5. They found six bugs in RouterOS. Two of them chain together into something they nicknamed MikroTrick.

CVE-2026-67276 is an SSH authentication bypass. RouterOS wasn't fully validating RSA public keys during login. If you knew a username and the public modulus of its key, you could craft an alternate key and get in without ever holding the private key. CVSS 9.2.

CVE-2026-86060 is a privilege escalation. RouterOS mishandled SSH usernames that start with disallowed characters. Log in as "-2" and you come out the other side with full admin. Also 9.2.

Chain them and you get unauthenticated administrative control of the router from anywhere on the internet. No credentials. No phishing. No user clicking anything. Just a port that was open.

Fixed versions are 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. If you're below those, stop reading and go patch.

Who's doing this

Raiu traced the activity to a Leaseweb IP, 82.192.72.4, with a second at 103.102.31.18. The staging server was hosting a busybox binary from 2010, a Python FTP server, and a launch script. Not nation-state polish. This looks like someone who either had the bug already or reverse-engineered the patch fast, and started farming routers.

Which is the point. MikroTik withheld technical details in its advisory "to give time to update your systems." That's the right call and it didn't matter. The exploitation predates the advisory. Whoever this is didn't need MikroTik to explain anything.

Raiu's estimate was one to two days before public exploit code landed on GitHub. A proof of concept is already listed. So the window is closed. Everyone has it now.

How to know if you're hit

This is the useful part, and Raiu deserves credit for making it simple.

Check your router log for "login failure for user -2 from <IP> via ssh." That's an exploitation attempt. It doesn't mean they got in, but it means you were on the list.

Then check /system history. If you see entries tagged ssh:-2@<IP> attached to configuration changes, you were compromised. Full stop. Look for a user named "ops." Look for new SSH keys, changed firewall rules, new proxies, tunnels, scheduler tasks, or packet sniffer settings you didn't create.

MikroTik built a compromise scan into the patched versions. After you upgrade, the device checks itself and writes a "Flagged" status to the log if it finds something. Useful. But don't treat a clean result as an all-clear, and don't treat a flagged device as something you can tidy up by deleting the "ops" user. CERT Polska's guidance is isolate and factory reset. Follow it. A router that's been owned at the admin level can be carrying config you'll never find by eye.

The part nobody wants to hear

MikroTik's advisory says most configurations aren't at risk and home users with default firewall rules are fine. True, and beside the point.

MikroTik routers aren't mostly in homes. They're in MSP racks, small ISPs, hotels, branch offices, and the closet of every SMB that had a competent contractor five years ago and hasn't touched it since. They're cheap, capable, and everywhere. That's exactly why they've been a botnet favourite for the better part of a decade. VPNFilter went after them in 2018. The same year, a cryptojacking campaign walked through more than 200000 of them using a Winbox bug. Same hardware. Same problem. Different CVE.

And a lot of those devices have SSH open to the world because someone needed remote management in 2019 and never got around to putting it behind a VPN or an allow-list.

A compromised edge router hands an attacker everything. They see every packet leaving your network. They can redirect DNS. They can stand up a tunnel back into you. They can sit there quietly for a year as a relay for someone else's attack, so when the RCMP knocks it's your IP in the logs. And none of your endpoint tools see any of it, because the router isn't an endpoint.

That's not theory. That's how every MikroTik botnet since 2018 has worked.

What this means if you run infrastructure for a living

Patch fast is correct advice and it isn't enough. You cannot patch a zero-day faster than zero. The only thing that saves you in the 24 hours before a fix exists is that the attacker couldn't reach the service in the first place.

So the real question for every MSP and IT lead reading this isn't "did we patch." It's "why was SSH on a WAN interface at all."

Management interfaces belong behind something. A VPN, a jump host, an allow-list of the three IPs that legitimately need in. Pick one. If your remote management story is "port 22 is open but we use strong passwords," this incident just demonstrated that the password didn't matter. The auth bypass never asked for it.

Then inventory. If you can't produce a list of every MikroTik you're responsible for, with firmware versions, in under an hour, you don't have an inventory. You have a guess. Every MSP I've assessed that got burned by an edge device had the same line: "we didn't know that one was still out there."

And build the assumption of compromise into the patch itself. Upgrading isn't the response. Upgrading, then reading the log, then checking history, then rebuilding the flagged ones, is the response. Half the value here is in the checking, and it's the half that gets skipped when you have 400 devices and it's Friday.

One honest caveat

We don't know the scale yet. Nobody has published a victim count, and the disclosure came with no attribution either. It's possible this stays a modest campaign by one operator. I doubt it, because the exploit is public and MikroTik's install base is enormous, but the data right now says "we'll see."

What doesn't change is the pattern. Cheap edge device, management port on the internet, bug in the auth path, patch that arrives after the first victims. We've seen it with Fortinet, Ivanti, Cisco, Citrix, and now MikroTik again. The vendor names rotate. The exposed port doesn't.

Bottom line

Patch today. Check the logs before you call it done. Rebuild anything flagged. Then go find every management interface your organization has facing the internet and ask why it's there.

The next one of these won't come with a warning either.