Three things break the day you find a MikroTik you forgot you owned: your assumption that the edge is patched, your assumption that SSH was firewalled off, and your Friday. There’s always one — the site router installed by a contractor in 2019, still humming, still reachable from the internet on port 22. That’s the box being hijacked right now.
Is my MikroTik actually vulnerable, or is this another over-hyped router scare?
It depends on two things: whether SSH is reachable from the internet, and whether your RouterOS version is one MikroTik lists as affected. If both are true, treat it as exploitable today. This is being described as a pre-authentication SSH bypass — an attacker doesn’t need a password, a key, or a foothold. They need a route to your SSH port. Reports of active exploitation go back to at least 5 September 2026, when CERT Polska raised the alarm. MikroTik patched late last week.
If your SSH is bound to a management VLAN or a VPN and has never faced the internet, your blast radius is small. If it’s answering on the WAN, keep reading and assume the worst.
Which versions are affected, and which one do I patch to?
Pull the exact affected and fixed version strings from MikroTik’s own security advisory — don’t take mine, don’t take a forum post’s, and don’t take a scraped table’s. Vendors get precise about version boundaries for a reason, and this is one story where an off-by-one in the version number means you patched into a still-vulnerable build. Check your running version first:
Match that against the advisory’s fixed release, then verify the fixed version exists on the update channel you actually use (stable vs long-term behave differently). At time of writing there is no CVE assigned yet that I can confirm from MITRE — so don’t go searching for a CVE ID to feel reassured. The absence of a CVE is not the absence of a problem.
How do I tell if SSH is exposed to the internet?
Check the service binding and its address restriction. On the router:
In the /ip service print output, look at the ssh row. If disabled is no and the address column is blank, it’s listening to the entire internet. An address value like 10.0.0.0/8 or your VPN range is what you want. From outside, a quick nc -vz your.public.ip 22 from a network you trust tells you the same thing in ten seconds. If it answers, so does everyone else’s scanner.
How do I check whether someone’s already in?
List every account and read it like you don’t trust any of it — because you don’t. Rogue admin accounts are the reported persistence move here.
Red flags: any account you didn’t create, an account with a blank or unfamiliar comment, an admin whose allowed-address is 0.0.0.0/0, or a last-login timestamp that lines up with the exploitation window. Attackers are not always subtle — sometimes it’s a fresh full-group user with a plausible-looking name. Sometimes it’s your own admin account with a changed password and a new source restriction. Write down what you find before you touch anything; you want the evidence, and you want to know whether to rebuild or just clean.
They released a patch. Am I safe once I install it?
No. This is the part that catches people. The patch closes the door; it does not evict whoever already walked through it. If an attacker added an account, dropped a scheduler, or changed a config before you patched, all of that survives the upgrade. Patching a compromised router just gives you a fully-updated compromised router.
What persistence do I look for beyond rogue accounts?
Widen the net. Config-based persistence on RouterOS doesn’t need malware — it just needs your own features turned against you:
You’re looking for a SOCKS proxy you didn’t enable, NAT rules that forward traffic through your box, schedulers that re-create a user or re-open a service on a timer, and DNS servers pointed somewhere unfamiliar. If a scheduler quietly recreates a deleted admin account, you’ll delete the account, feel clever, and find it back in the morning.
Should I just patch over my existing SSH session and move on?
No — and this is not pedantry. If you’re administering the device over the same SSH service that’s implicated, you may be doing it over a session an attacker can see or ride. Do remediation from a trusted network segment: console cable, Winbox over a management VLAN, or an out-of-band path. Not over the potentially compromised WAN-facing SSH you’re trying to fix.
What do I do if I can’t patch this minute?
Take SSH off the internet immediately. That single change removes the reachable attack surface while you plan the upgrade:
Belt and braces: add a firewall rule dropping inbound TCP/22 on the WAN interface, and confirm no other service (Winbox, API, WWW) is needlessly exposed either. Same rule applies — restrict or disable, don’t hope.
Do I need to wipe the router or just clean it?
If you found any sign of compromise — an account you can’t explain, a scheduler you didn’t write, a service you didn’t enable — rebuild from a known-good config, not from the running one. Netinstall or a clean import beats playing whack-a-mole with an attacker who had root. If the box is provably clean and you caught the exposure before exploitation, patch and re-restrict SSH and you’re done. When in doubt, rebuild. The router costs less than the incident.
How urgent is this, really?
Immediate. Pre-auth, actively exploited, full device takeover, on a router that plenty of people forgot is even internet-facing. Every hour an exposed box stays up is an hour someone can add persistence that outlives your patch. Tonight: get SSH off the WAN. This week: enumerate every MikroTik you own — including the ones not in your asset inventory — patch to the advisory’s fixed version, and audit accounts and config on anything that ever faced the internet.
The router you’re most worried about is the one you didn’t remember to worry about. Go find it first.
