CERT Polska says attackers are actively chaining two MikroTik RouterOS vulnerabilities in a campaign it calls MikroTrick. A vulnerable router is at immediate risk when its SSH service is reachable from the public internet: the chain can bypass normal authentication conditions and end with full administrative control. The priority is to update RouterOS, close or restrict public SSH, and then check whether the device was already changed.
This is not a claim that every MikroTik router has been compromised. The default RouterOS configuration blocks unsolicited management access from the internet, so the highest-risk group is devices whose administrators deliberately exposed SSH or otherwise made it reachable. Owners of those systems should not treat a successful update as proof that the earlier state was clean.
Which RouterOS versions need attention?
CERT Polska lists the vulnerable ranges and the first builds containing the security fixes. MikroTik later released RouterOS 7.23.5 after an IPv6 regression in 7.23.4, so administrators on the long-term channel should install the current superseding build rather than stop at 7.23.4.
| Installed branch | Minimum practical action |
|---|---|
| RouterOS 7.24 through 7.24.1 | Update to 7.24.2 or newer |
| RouterOS 7.0.0 through 7.23.3 | Update to the current long-term build, 7.23.5 or newer |
| RouterOS 6.0.0 through 6.49.20 | Update to 6.49.21 or newer |
| Development builds before 7.25beta3 | Update to 7.25beta3 or newer |
If the device cannot be updated because the hardware is unsupported, remove it from internet-facing service and plan a replacement. Do not leave an old branch reachable merely because no warning is visible.
How the MikroTrick chain works
The attack joins CVE-2026-67276, an authentication weakness involving RouterOS handling of RSA public keys, with CVE-2026-86060, a privilege-handling flaw in authenticated sessions. CERT Polska reports that the combination has been used to obtain full control without a valid login on exposed devices. This article intentionally omits crafted inputs and reproduction steps.
A separate issue, CVE-2026-67277, affects the RouterOS bandwidth-test service and can expose memory or cause a denial of service. It is fixed in the same release families, but CERT Polska’s observed router-takeover activity centers on the first two flaws.
Full router control matters because a router is a trust boundary. An intruder can alter accounts, firewall rules, scripts, scheduled tasks, DNS behavior, proxies, or tunnels. Those capabilities describe what an administrator must audit; they do not prove that every compromised device was used for each purpose.
Check exposure and compromise separately
| What you find | What it means |
|---|---|
| SSH was never public and the firewall remained at its default | Immediate exposure is lower, but the fixed build is still the safe baseline |
| SSH was public while the router ran a vulnerable build | Treat the device as exposed and preserve logs and configuration before making changes |
Flagged: yes, an unknown privileged account, or unexplained configuration changes |
Handle the router as potentially compromised; an update alone is insufficient |
| No obvious warning after updating | This is not proof of a clean earlier state because RouterOS flags only selected suspicious changes |
Useful signs from the CERT advisory include a critical SSH login-failure entry with the indicator value -2, a user-add event attributed to an SSH session with that marker, and an unexpected privileged account named ops. Also inspect users, scripts, scheduled tasks, SOCKS or HTTP proxies, firewall rules, DNS, and tunnels for anything you did not create. Do not delete the evidence before recording it.
What RouterOS administrators should do now
- Record the current state. Save logs and a configuration export to a protected location. Note the installed version and whether SSH was reachable from the internet.
- Install the fixed/current build for your channel. Verify the package came from MikroTik and confirm the running version after reboot.
- Remove unnecessary exposure. Disable public SSH, restrict it to trusted source addresses, or require administrators to connect through a VPN. Review every other management service too.
- Audit the device. Check
/system/device-mode/printfor the Flagged state, then review accounts, keys, scripts, jobs, proxies, tunnels, DNS, and firewall changes. - Recover decisively if indicators appear. Isolate the router, retain evidence, factory-reset it, and rebuild manually from a known-good design. Do not blindly restore the full prior configuration.
- Rotate exposed secrets from a clean device. Replace RouterOS passwords and SSH keys, then rotate VPN, Wi-Fi, administrative, and service credentials that passed through or were stored on the router.
For the broader distinction between a router compromise and an infected endpoint, see our guide to how routers get hacked and what changes. The recent QTFY router botnet disruption is another reminder that losing the management plane can turn a network appliance into someone else’s infrastructure.
Patch first, but do not stop there
The safest short version is simple: a MikroTik router with internet-accessible SSH and a vulnerable RouterOS build deserves immediate attention. Updating closes the known path. Exposure review tells you whether the path was reachable. Configuration and log review help determine whether recovery and credential rotation are necessary. Those are three separate questions, and answering only the first can leave an earlier compromise in place.
