MikroTik Routers Under Attack: Check Yours Today

Attackers began hijacking internet-exposed MikroTik routers on 2 September 2026, one day before MikroTik shipped the fix. The chain, named MikroTrick by Poland's national CERT, needs no password and ends in full administrator control. The reported September count included 7,100 exposed devices in Indonesia. Update to a current fixed release, then check for signs of a break-in. The October correction below matters even if you already patched in September.

What actually happened?

MikroTik published patched RouterOS builds on 3 September 2026 — 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21 — with a short note saying most configurations were not at risk. Two days later CERT Polska disclosed six vulnerabilities and confirmed that two of them, chained together, were already being used against real devices from at least 2 September. Exploitation began before the patch was available.

Two of the six carry a severity score of 9.2 out of 10 on CVSS, the industry's standard 0–10 scale for how bad a flaw is:

• CVE-2026-67276 breaks SSH login. SSH is the remote command line administrators use to configure a router without standing in front of it.
• CVE-2026-86060 turns a limited SSH session into a full administrator one — what security people call privilege escalation.

A third, CVE-2026-67277 (8.8), sits in the bandwidth-test service, the built-in speed-test tool RouterOS ships enabled on many builds. It leaks raw memory contents and can be crashed remotely.

Publicly reachable SSH exposes the attack surface. For the RSA-key bypass described below, CERT Polska also identifies knowledge of the username and the public modulus of an assigned key as prerequisites. MikroTik’s October advisory separately lists CVE-2026-67279 as an SSH command-execution flaw observed in the wild; do not treat every SSH flaw as the same mechanism.

Why does this hit Indonesia harder?

Because of where the boxes are. As of 5 September 2026 the Shadowserver Foundation counted 122,500 MikroTik devices with SSH open to the internet: Brazil 11,300, the United States 7,100, Indonesia 7,100, Czechia 6,300, Ukraine 5,100. Indonesia is MikroTik's third-largest market by tracked business customers, behind only Brazil and the US.

That ranking is not a trivia fact. In Indonesia a MikroTik box is the default answer for a neighbourhood ISP (RT/RW net — community-scale internet resold street by street), a hotel's guest WiFi, a boarding house, a small factory's office link, and the site router in front of every IoT gateway I get called out to. One vendor, one operating system, one advisory — and a very large number of buildings.

The router is also the worst device to lose. It sees every packet in the building, holds the VPN keys to head office, and nobody watches its logs. An attacker who owns it does not need to break anything else. Post-compromise activity reported by CERT was exactly that: new user accounts, added SSH keys, rewritten firewall rules, and fresh proxies and tunnels — quiet plumbing for someone else's traffic to ride through your building.

How does the attack work?

Think of SSH key login as a doorman comparing the key you present against the key on file. An RSA key has two published parts: a very long number called the modulus, and a small number called the exponent. RouterOS compared the key type and the modulus, then stopped. It never checked the exponent. Present a key with the right modulus and an exponent of 1, and the doorman waves you through as that user without you ever holding the real private key.

The second flaw is stranger, and it explains the fingerprint everyone is now grepping for. RouterOS mishandled usernames that begin with a disallowed character. Log in as the username -2 and the login path treats it as an argument rather than a name, altering the permission mask attached to the session. Limited access becomes administrator access.

Each flaw is serious on its own: authentication bypass can grant the targeted account's privileges, and the second flaw can escalate access. Combined, they permit administrator takeover without the expected credentials.

What should I check right now?

Read first, change second. If the device turns out to be compromised, you want the evidence intact before you start typing. Commands below use the RouterOS 7 slash syntax; on 6.x drop the slashes (/system resource print).

1. Version. Check the release branch against the advisory. The September fixes were 7.24.2, 7.23.4 and 6.49.21. In its 6 October 2026 update, MikroTik said the fix for CVE-2026-67278 was incomplete in 7.24.2 and 7.23.4: use 7.24.3 (stable), 7.23.6 (long-term), or a later fixed release. RouterOS 6 is not affected by that particular issue.

/system/resource/print

2. Is SSH actually exposed? The address column is the allow-list. An empty value leaves the service unrestricted by that allow-list; actual internet reachability also depends on firewall rules and routing.

/ip/service/print

3. The compromise marker. Patched RouterOS 7 builds check for selected signs of unauthorised configuration changes at boot, disable recognized suspicious entries, and raise a Flagged state.

/system/device-mode/print

4. Users you did not create. A privileged account named ops is a confirmed indicator from the live attacks.

/user/print
/user/ssh-keys/print

5. The -2 fingerprint in logs and history. Failed logins for a user named -2, or history entries reading added by ssh:-2@<ip>.

/log/print where message~"-2"
/system/history/print

6. Persistence. Scripts and scheduler entries (RouterOS's built-in cron) run commands on their own; SOCKS proxies and tunnels carry someone else's traffic through your line.

/system/script/print
/system/scheduler/print
/ip/socks/print
/interface/print

Two attacker addresses seen in the campaign — 82.192.72.4 and 103.102.31.18 — are worth grepping your logs for, but treat them as a bonus. Absence proves nothing.

Restrict SSH to the actual trusted management network and disable services the deployment does not use. The subnet below is illustrative: verify your management path before applying changes so you do not lock yourself out.

/ip/service/set ssh address=10.0.0.0/8
/ip/service/set www,www-ssl disabled=yes
/tool/bandwidth-server/set enabled=no

Is patching enough?

Patching must be followed by inspection and recovery if there are signs of compromise.

Upgrading RouterOS closes the hole. It does not remove an account, key, scheduler entry, or tunnel that was added while the hole was open. Those are configuration, and configuration survives an upgrade by design. A device that was compromised on 3 September and patched on 8 September is a patched compromised device.

The Flagged marker helps, but CERT is blunt about its limits: the absence of a marker is not a guarantee of a clean device. Logs roll over. Attackers clean them.

So the rule is boring and unpopular. If you find any indicator — an unknown user, a -2 line, a scheduler entry nobody wrote — do not clean it item by item. Isolate the device, export the logs and configuration for evidence, factory reset, rebuild from a configuration you trust, and rotate every password, SSH key, VPN secret and RADIUS secret that box ever held. CERT.LV confirmed 12 compromised devices in Latvia out of several thousand exposed as of 6 September; the ratio is low, but the cost of guessing wrong on one of them is the whole network behind it.

Rebuilding from last night's backup is not a rebuild if the backup already contains the attacker's user account. Check the export, do not just restore it.

How do I make the next advisory boring?

There will be another one. The question is whether the next disclosure costs you an afternoon or a weekend.

Keep the management side off the public internet. SSH, Winbox and the web interface belong behind a VPN, not on a port. MikroTik's own advice on this advisory was to reach devices over WireGuard. This limits exposure to the SSH attack path; it does not replace installing security updates.

Know what you have. Model, RouterOS version, location, and who owns the password — for every site. Most operators I meet cannot answer "how many routers are below 7.23.4" in under a day, and that answer is the whole response time. The same argument applies to every device class: a CCTV fleet fails the same way, for the same reason.

Watch the boxes you already own. A router that gains a user account at 3 a.m. should page somebody. Config-change alerting on network gear costs almost nothing and is the difference between five days of quiet tunnelling and a same-night response — the small-system monitoring case in miniature.

Subscribe to the vendor's advisory page. MikroTik posted on 3 September. The public exploit details landed on 5 September. That 48-hour gap is the window operators are handed, and it only helps the ones who are reading.

The uncomfortable part of this incident is not the flaw. It is that the flaw was being used before the patch existed, which means no amount of fast patching would have saved a device with SSH facing the internet. What saved devices was a decision made months earlier, on a quiet day, about which ports face outward. That decision is still available to you today.