MikroTik patches routers hijacked over internet-exposed SSH
CERT Polska warns that attackers are taking full administrative control of MikroTik routers whose SSH service is reachable from the internet, without authentication. Update RouterOS and audit the configuration before putting any device back into service.
September 5, 2026. Poland’s national CSIRT, CERT Polska, publishes an attack warning covering MikroTik routers whose SSH service is reachable from the internet. Successful attacks date back to at least September 2, 2026, and the vendor has already shipped RouterOS fixes across several channels. Why it matters: a router carries every packet on a network — compromising it without authentication hands the attacker a vantage point and a pivot across the whole environment.
Administrative access without authentication
The attackers exploit the router’s SSH service when it is reachable from the internet, gaining full administrative control of the device without authentication. CERT Polska names the two-flaw combination “MikroTrick”, but the warning does not publicly identify the two vulnerabilities that form the chain, nor explain exactly how they combine to yield root access.
That technical silence changes nothing about the urgency. The warning lists no victim count and no attacker identity as of The Hacker News’s September 6, 2026 review. The decisive point lies elsewhere: the attack succeeds without any stolen password, which means simply exposing a management port is enough to turn a router into a controlled machine.
Full administrative control over a router is more damaging than it sounds. The attacker can redirect traffic, strip TLS, inject DNS answers, and observe every connection that crosses the device. Because a router sits below application-level defenses, none of this leaves logs on the endpoints behind it — which is exactly why the recovery sequence below starts with preserving evidence rather than reflashing.
Zero-day status remains unresolved. The 7.25beta3 release notes carry a September 2 changelog date, while the first fixes were announced on September 3. The timeline does not establish whether a patch was publicly available before the attacks began.
Affected versions and fixes
CERT Polska lists the affected ranges and the releases that stop the observed attack. The essentials of MikroTik’s published versions are below.
- RouterOS 6, from 6.0.0 up to 6.49.20: upgrade to 6.49.21 (the RouterOS 6 security release).
- RouterOS 7, from 7.0.0 up to 7.23.3: upgrade to 7.23.4, or 7.23.5 on the long-term channel.
- RouterOS 7.24 through 7.24.1: upgrade to 7.24.2 (the stable channel security release).
- Development channel: the fix ships in 7.25beta3.
One version detail matters: 7.23.5 fixes an IPv6 DHCP regression introduced in 7.23.4 while keeping the security patch. On the long-term channel, prefer 7.23.5 over 7.23.4.
The exposure surface: SSH, WWW, bandwidth-test
MikroTik’s default firewall blocks public access to management ports as long as its rules stay intact. The problem appears when that protection is disabled or edited — a common habit among administrators who manage routers remotely without going through a VPN.
Attackers do not stumble onto these devices. Public scanning services index internet-facing RouterOS boxes by banner and version, and automated tooling can flag an exposed management port in seconds. An internet-reachable SSH service is effectively a standing invitation, catalogued long before an attacker ever touches it.
Until the update can be applied, CERT Polska recommends turning off exposed services or restricting them to trusted management networks, especially SSH, WWW/WWW-SSL, and bandwidth-test. It also advises against initiating TLS connections or using RouterOS’s built-in SSH clients from an unpatched device — these temporary restrictions cover a broader set of vulnerabilities and do not replace the update.
# Disable exposed SSH while waiting for the update
/ip service disable ssh
/ip service disable www,www-sslThe message is unambiguous: until the router is patched, the only safe posture is to pull every management service off the public network.
What to inspect after the update
The update alone is not enough. A router that was already compromised stays compromised after patching, because the attacker may have planted scripts, accounts, or rules that persist. CERT Polska recommends several checks after reboot.
First, RouterOS has a “Flagged” status: it triggers when startup checks detect a suspicious configuration, disabling those entries and restricting certain functions. The command below prints that status.
/system device-mode printNext, review the logs and configuration for unknown users, scripts, and any unrecognized changes. CERT Polska points to two concrete signals: unexpected highly privileged “ops” accounts, and account-creation logs containing “ssh:-2@”.
/user print
/system script print
/log print where message~"ssh:-2@"The ssh:-2@ marker deserves a note: it indicates an inbound SSH login that resulted in account creation through a non-interactive path — the exact profile of attack automation rather than human administration. Its presence in the logs is a reliable sign of compromise, even with no other visible anomaly, so review the logs even when the device shows no Flagged warning.
If the warning, the logs, or the configuration suggest compromise, do not clear the Flagged status before preserving evidence and completing the analysis.
What to do once a compromise is confirmed
When compromise is established, CERT Polska prescribes a strict sequence, in this order.
- Isolate the router from the network and preserve its logs and configuration before any reset.
- Restore factory settings and rebuild from a trusted, verified configuration — do not blindly restore a full backup taken from the potentially compromised device.
- Change passwords, keys, and other secrets in use across the environment, since they may have been collected during the compromise.
This sequence applies to any network-device compromise, not just MikroTik: a controlled router may have observed traffic, stolen credentials, and pivoted into the rest of the network. Treating it as a device to “just reflash” understates the blast radius.
Why MikroTik keeps getting targeted
MikroTik routers are not hit by chance. Their power-to-price ratio, their dense presence at ISPs and wireless operators, and the share of installs left on default settings have made them a favorite botnet target for years.
In 2018, the Winbox flaw CVE-2018-14847 let attackers read sensitive files from the router. It was exploited at scale: more than 200,000 devices were infected with cryptocurrency miners and turned into SOCKS proxies.
In 2021, the Meris botnet — assembled from roughly 200,000 MikroTik routers — launched denial-of-service attacks of record intensity, striking Yandex among others.
That history reframes the current episode. A MikroTik compromise is almost never isolated: infected devices join persistent infrastructure that gets reused for later attacks. The right response is therefore not only to patch, but to verify the actual state of every exposed device before putting it back into service.
Verdict
If you expose a MikroTik router over SSH on the internet, update RouterOS to a fixed release now — 6.49.21, 7.23.5, 7.24.2, or 7.25beta3 depending on your channel — then remove direct exposure of management services.
If the router has been exposed since September 2 at the earliest, don’t stop at patching: isolate, preserve logs, inspect accounts and scripts, and rebuild only from a trusted configuration.
If you want to remove the whole risk class, stop administering network equipment over raw internet SSH: a VPN or a dedicated management network closes the door “MikroTrick” walks through, whatever the next flaw turns out to be.