Attackers are exploiting MikroTik RouterOS vulnerabilities to take full administrative control of routers when SSH is reachable from the public internet.
Successful attacks have been observed since at least September 2, one day before MikroTik released patched RouterOS builds. Administrators need to update vulnerable devices immediately and check whether attackers gained access before the fixes were installed.
CERT Polska identified six RouterOS vulnerabilities and confirmed that attackers are actively using a two-flaw chain it named MikroTrick. The chain can take over an internet-exposed device without authentication, and CERT says the released patches stop the attacks it has observed.
Which MikroTik RouterOS vulnerabilities were disclosed
Two of the six vulnerabilities received CVSS scores of 9.2.
CVE-2026-67276 is an SSH authentication bypass involving incomplete verification of RSA public keys. An attacker who knows a username and the public modulus of an authorized RSA key can potentially authenticate without possessing the corresponding private key.
CVE-2026-86060 affects the way RouterOS handles certain SSH usernames. A crafted username can manipulate the policy assigned to the resulting session and lead to full administrative privileges.
The remaining flaws include CVE-2026-67277 in the bandwidth-test service, CVE-2026-67278 in X.509 certificate validation, CVE-2026-67279 in the SSH authentication state, and CVE-2026-67281 in the WebFig interface. Full technical descriptions are available in CERT Polska’s CVE advisory.
The active-exploitation alert does not identify the two CVE numbers used in the attacks CERT observed. Researchers at Tolmo independently reproduced an unauthenticated takeover using CVE-2026-67279 with CVE-2026-86060.
That reproduced path starts with the SSH state flaw. After a client-requested rekey, CVE-2026-67279 can let an unauthenticated client reach a session state that should require authentication. CVE-2026-86060 can then turn that session into one with full RouterOS permissions.
For defenders, the active exploitation and internet exposure make these vulnerabilities higher priorities than their individual scores alone might suggest, an approach increasingly used in vulnerability management beyond CVSS.
Which RouterOS versions contain the fixes
MikroTik lists fixes in:
- 7.25beta3
- 7.24.2
- 7.23.4
- 6.49.21
MikroTik recommends upgrading even when a configuration is not immediately exposed. Its default configuration blocks SSH access from the internet, but devices where administrators opened SSH to untrusted networks face the clearest risk from the observed attacks.
If patching cannot happen immediately, CERT recommends restricting SSH, WWW/WWW-SSL, and bandwidth-test access to trusted management networks. Administrators should also avoid outbound TLS connections and RouterOS’s built-in SSH client from an unpatched device.
Reducing exposed management services can shrink the immediate attack surface, but it does not replace installing the security update.
Check RouterOS devices for signs of compromise
Updating closes the known vulnerabilities, but it does not show whether a device was compromised beforehand.
Patched RouterOS releases check the configuration during startup for known signs of unauthorized changes. When suspicious configuration is detected, RouterOS can disable recognized entries, write a critical log message, and set the device to Flagged status.
Administrators can check the marker with:
/system/device-mode/print
A router that is not Flagged should not automatically be considered clean. CERT says the mechanism detects only selected traces of compromise.
Known indicators include:
login failure for user -2 from <ip> via sshuser <name> added by ssh:-2@<ip>- An unexpected highly privileged user named
ops - Successful attack activity from
82.192.72.4 - Exploitation attempts from
103.102.31.18
CERT traced the successful attacks it analyzed, including creation of the ops account, to 82.192.72.4. The activity dates back to at least September 2.
Administrators should also inspect users, scripts, scheduler tasks, proxy servers, tunnels, and other configuration changes they do not recognize. The absence of the published indicators does not rule out unauthorized activity.
What to do if a MikroTik router was compromised
A Flagged device or other evidence of compromise should trigger incident response, not just removal of the suspicious account or configuration entry.
Isolate the router and preserve its logs and configuration before resetting it. Do not clear the Flagged marker before collecting the evidence needed for investigation.
After that evidence is secured, restore the device to factory settings and rebuild it from a trusted configuration. Rotate passwords, keys, and other secrets that may have been accessible through the router.
Do not blindly restore a full backup taken from the potentially compromised device. Malicious users, scripts, scheduled tasks, or other unauthorized configuration could be restored with it.
The same principle applies to broader cyber resilience and recovery: bringing a device back online is not enough unless its configuration can also be trusted.
Patch first, then investigate
Any affected RouterOS device should be updated immediately, with internet-exposed SSH receiving the highest priority.
For routers that were vulnerable and publicly reachable on or after September 2, patching should be followed by log and configuration review. A successful upgrade prevents the attacks addressed by the fixes, but it cannot undo access an attacker already gained.
Check the RouterOS version, restrict management access, review the Flagged status, hunt for the published indicators, and investigate any configuration that does not match the known-good state.
Also read: Google patched Chrome’s sixth exploited zero-day of 2026 after confirming that CVE-2026-85046 was being used in attacks.