Attackers were taking full administrative control of Internet-facing MikroTik routers over SSH without a password, without an SSH key, and without ever completing authentication. The chain, named MikroTrick by CERT Polska, was being used in the wild at least a day before MikroTik shipped patches. If a MikroTik router sits in front of your servers or hosting infrastructure, this is one to take seriously, because a compromised edge router is not just a compromised router. It is a foothold in front of everything behind it.
We see MikroTik gear constantly on the perimeter of hosting setups and server infrastructure we manage, and the reason this attack matters is that the router is the one device that sees all your traffic and holds the keys to your network layout. Here is how the chain works, how to tell if you were hit, and what to do about it.
The chain: two flaws that are weak alone and devastating together
MikroTrick combines two separate RouterOS SSH vulnerabilities. Neither one is game over by itself. Stacked, they hand over the whole device.
Step one: skipping authentication (CVE-2026-67279)
Normal SSH runs in a strict order. It sets up an encrypted connection, authenticates the user, and only then lets the client open a session and run commands. The server sends a specific confirmation message once authentication passes, and nothing should proceed without it.
CVE-2026-67279 breaks that order. If the client kicks off an SSH key renegotiation during the authentication step, vulnerable RouterOS jumps straight to the command phase once the renegotiation finishes, without ever confirming who the user is. On its own this does not create an authenticated session or grant privileges. What it does is let an unauthenticated stranger reach a stage that is supposed to be locked behind a completed login. That is the door being propped open.
Step two: becoming admin through the login program (CVE-2026-86060)
This is the clever part, and it is a textbook argument-injection bug. When a session comes in, RouterOS runs a login program at /nova/bin/login, and the SSH daemon passes it the username and a privilege level as command-line arguments. The problem: it does not validate the username first. A value that starts with a hyphen gets treated as a program option, not as a name.
So the attacker sends -2 as the username. The login program reads that as an instruction to pull its identity and privilege level from file descriptor 2, which happens to point at the terminal the SSH session created. And through the SSH channel the attacker has already written their chosen username and a full-admin privilege value into that very terminal. The login program dutifully reads both and opens a fully privileged console. No credential ever changed hands.
That is the whole trick: one bug gets you to the login stage without authenticating, the second bug tells the login program to trust input the attacker controls.
This was exploited before the patch existed
This is not a theoretical chain. CERT Polska found attack logs dating to at least September 2, one day before MikroTik released fixes on September 3. CISA independently confirmed active exploitation by adding CVE-2026-86060 to its Known Exploited Vulnerabilities catalog on September 10.
The attack leaves a very recognizable footprint. On one device documented on the MikroTik forum, the sequence was: a rejected login for user -2, a forced renegotiation, a jump to the channel phase, and an exec request trying to create a user called ops with full privileges. On that particular device the SSH process crashed before the command finished, but other reports confirmed the ops account was successfully created elsewhere. In some incidents CERT Polska saw diagnostic files being generated and then data transferred out to an attacker IP, which strongly suggests router configuration was copied off to attacker infrastructure. Your config is your network map, your firewall rules, your VPN secrets. That is exactly what you do not want in someone else’s hands, and it is exactly the gap a properly configured perimeter firewall in front of admin-facing services is meant to close.
Fixed versions, and who is actually at risk
MikroTik patched the chain in RouterOS 6.49.21, 7.23.4, and 7.24.2. Update to at least these builds on the release line you run.
The precondition for attack is that SSH is reachable by the attacker. MikroTik says its default home configuration does not expose SSH to the Internet, so out-of-the-box home units are largely out of scope. The higher-risk group is everyone who changed their firewall rules or manages devices over SSH from untrusted networks, which describes a lot of real-world hosting and business deployments. If you administer your MikroTik remotely over SSH, assume you are in the target set.
One point of clarity, because some outlets got it wrong: MikroTrick is specifically CVE-2026-67279 plus CVE-2026-86060. A third flaw, CVE-2026-67276, has been incorrectly lumped in. CERT Polska says that one is a separate SSH bug that lets an attacker forge an RSA key to log in as an existing user, but it requires knowing the account name and its public key and only gives access to that one account. Different bug, different severity. Patch for all of them, but do not confuse the two stories.
How to check whether you were compromised
Patching stops the attack going forward. It does not undo anything an attacker already did before you updated. This distinction is critical: a patched router is not automatically a clean router. After updating, check the device Flagged status with:
/system/device-mode/printBut do not lean on Flagged as proof of safety. Both CERT Polska and MikroTik are explicit that the Flagged mechanism only detects selected traces of compromise, and its absence does not prove the device is clean.
CERT Polska published these concrete indicators from observed attacks. Check for all of them:
- Username
-2appearing in SSH login logs. - An account named
opsin the full-privilege group. - Attacker IP
82.192.72.4, seen in successful attacks. - Attacker IP
103.102.31.18, used in exploitation attempts.
Beyond those, go hunting for anything you cannot explain: unknown users, unfamiliar scripts, scheduler entries, tunnels, proxies, unexpected .rif diagnostic files, or fetch activity you did not initiate. Those are the kinds of persistence and exfiltration artifacts this attack leaves behind.
If you find any of it: assume full compromise
If any indicator is present, treat the device as fully owned and do not try to clean it in place. CERT Polska’s guidance, which matches what we tell clients after any confirmed router compromise, is direct:
- Isolate the device from the network.
- Preserve its logs and configuration for investigation before you wipe anything.
- Factory reset it and rebuild from a configuration you trust, not from a backup taken off the compromised device. A backup from a compromised router can carry the attacker’s changes straight back in.
- Change every password, key, and credential the router touched. If the config was exfiltrated, assume everything in it is burned, including VPN secrets and any shared credentials.
If you are not confident you can do that isolate-and-rebuild sequence cleanly under pressure, that exact process is what our emergency incident response team handles for compromised infrastructure, not just compromised websites.
The takeaway
MikroTrick is a clean example of why chained vulnerabilities beat isolated ones, and why the network edge deserves the same patch urgency as your servers. An authentication-skip bug that grants nothing on its own, plus a sloppy argument-handling bug in a login helper, combine into unauthenticated full admin on a device that sees all your traffic. It was exploited before the fix was even out. If you run MikroTik with SSH reachable, update to 6.49.21, 7.23.4, or 7.24.2 now, then work through the indicators above, because the patch closes the door but does not evict anyone already inside. If you would rather have someone else confirm your edge devices are actually closed off, that is what our penetration testing and managed security hardening services are for.