If your organization runs a MikroTik router anywhere in the network, be it at a branch office, on a cell tower, at an ISP point of presence, or as a home-office VPN endpoint, this is worth reading today rather than later. MikroTik hardware is inexpensive, capable, and extremely widely deployed; it shows up in small business networks, service provider infrastructure, and hobbyist setups alike. That popularity is exactly why a new attack chain against it, publicly disclosed this week and already being used against real devices, deserves immediate attention.
The chain is called MikroTrick. Two vulnerabilities, tracked as CVE-2026-67276 and CVE-2026-86060, combine to let an attacker take complete administrative control of a MikroTik router with no username, no password, and no prior access of any kind, as long as the router's SSH service can be reached from the internet. Poland's national CSIRT team, CERT Polska, has confirmed that this exact combination is being actively exploited right now.
How this came to light
CERT Polska identified six vulnerabilities in RouterOS during a coordinated research effort with MikroTik. Two of them, when chained together, allow the unauthenticated takeover described above; CERT Polska gave that specific combination the name MikroTrick.
Notably, the vulnerabilities were found with the assistance of AI models, GPT-5.5-cyber and GPT-5.6-sol, through CERT Polska's participation in OpenAI's Government and Trust Agency Collaboration program; more on that discovery process below.
MikroTik shipped fixes across every release channel on September 3, 2026, in versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. In its initial advisory, MikroTik deliberately withheld technical details, stating it wanted to give administrators time to patch before attackers could reverse-engineer the flaw. That caution did not buy much time: forum users and independent researchers began piecing together the mechanics from the patched binaries almost immediately, and CERT Polska published its full advisory on September 5, 2026, once it had confirmed the vulnerabilities were already being exploited in the wild.
What is MikroTrick?
MikroTrick is not a single bug; it is two flaws in RouterOS's SSH handling that work together to defeat authentication entirely.
CVE-2026-67276: SSH authentication bypass (CVSS 9.2)
RouterOS is supposed to verify a user's full RSA public key when that user attempts to log in via SSH with a key instead of a password. Instead, it only compared the public modulus portion of the key. An attacker who knows a valid username and can obtain or guess that user's public modulus can construct an entirely different key sharing that modulus, present it during login, and be authenticated as that user, all without ever possessing the real private key.
CVE-2026-86060: SSH privilege escalation via a crafted username (CVSS 9.2)
Separately, RouterOS mishandled SSH usernames that began with a disallowed character. By crafting a username in a specific way, an attacker could manipulate the resulting session so that it carried full administrative privileges, regardless of which account was actually being impersonated.
Chained together, these two flaws let an attacker log in without any real credentials and land with full administrative control of the device. No prior foothold, no phishing, no stolen password; only network reachability to the SSH port.
Other vulnerabilities patched alongside MikroTrick
Beyond the two flaws that make up MikroTrick, four additional vulnerabilities were fixed in the same release. These are separate, unrelated bugs, not part of the chain itself.
The most significant of these is CVE-2026-67277 (CVSS 8.8), an issue in RouterOS's bandwidth-test service. It allows unauthenticated connections to reach a state that should only be reachable after login. Combined with a leak of uninitialized packet-buffer data and an integer underflow in a size check, this could expose kernel memory to an attacker or crash the device into a restart.
Three additional, lower-severity vulnerabilities were also fixed, affecting the SSH client, X.509 certificate handling, and the WebFig web management interface. CERT Polska has not published full technical detail on these, deliberately, to slow down attackers still working from the patch diffs.
What can an attacker actually do?
If a MikroTik router's SSH service is reachable from the internet or from an untrusted network and it has not been patched, an attacker can gain full administrative control without authenticating at all. From there, they can create new privileged accounts, add scripts and scheduled tasks, reconfigure the firewall to open further access, redirect or intercept traffic passing through the router, use the device as a proxy or pivot point into whatever network sits behind it, or simply take the router offline.
For an edge device, a router sitting between an internal network and the internet, that level of control is close to the worst case: everything downstream of it is potentially exposed, and the compromise may be invisible from inside the network it is supposed to protect.
MikroTik's own guidance is a useful reality check on scope, though: the company's default firewall configuration blocks SSH and other management ports from the internet out of the box. Devices are only exposed if an administrator has deliberately opened SSH to the world, which is common in ISP and business deployments that rely on it for remote management, but is not the out-of-the-box state for most home routers.
Who is affected?
The vulnerabilities span a broad range of RouterOS releases across both the legacy and current branches:
| Branch | Affected Versions | Fixed In |
|---|---|---|
| RouterOS 6 (legacy) | 6.0.0 up to (not including) 6.49.21 | 6.49.21 |
| RouterOS 7 (stable) | 7.0.0 up to (not including) 7.23.4 | 7.23.4 (7.23.5 recommended; see below) |
| RouterOS 7 (stable) | 7.24 up to (not including) 7.24.2 | 7.24.2 |
| RouterOS 7 (development) | Not specified by CERT Polska | 7.25beta3 |
One wrinkle worth flagging for planning purposes: MikroTik's 7.23.4 release introduced a regression affecting IPv6 DHCP. A follow-up release, 7.23.5, fixes that regression while retaining the security patch, so long-term channel users should target 7.23.5 rather than stopping at 7.23.4.
The exposure condition is what matters most here. A device is only reachable by this specific attack chain if its SSH service, or another affected service such as bandwidth-test or WebFig, is accessible from an untrusted network. Home users on MikroTik's default firewall configuration are not directly exposed, though MikroTik still recommends everyone upgrade. Organizations that rely on SSH for remote management of routers at branch sites, at customer premises, or on cell infrastructure should treat this as an urgent, internet-facing concern rather than routine maintenance.
The scale of the exposure
The Shadowserver Foundation reported that, as of a 24-hour scan window on September 5, 2026, it found approximately 122,500 MikroTik devices with SSH accessible from the internet. That figure counts SSH exposure alone, without checking whether a given device's SSH implementation is actually running a vulnerable RouterOS version, so it should be read as an upper bound on the immediately reachable attack surface rather than a confirmed vulnerable-device count.
That number is narrower than a broader count of MikroTik RouterOS devices visible on the internet across all services, which unsurprisingly runs considerably higher; a general query run on Shodan.io for internet-facing MikroTik RouterOS instances, for example, commonly returns figures well north of 400,000. The gap between that broader figure and Shadowserver's SSH-specific count is a useful reminder that most internet-facing MikroTik devices are not exposing SSH itself, even though a large minority clearly are. We were not able to independently verify a current SSH-specific count via Shodan, so the Shadowserver figure, coming from a scan run for this exact purpose on September 5, is the number we would lean on for sizing the immediately reachable attack surface.
Either way, whether the realistic number of internet-reachable SSH endpoints is closer to 122,500 or higher, it represents a large population of devices that are one unauthenticated login away from full compromise until they are patched.
Active exploitation: what we know
CERT Polska has directly confirmed that MikroTrick is being used in real attacks, not merely that it is theoretically exploitable. The team traced confirmed successful compromises, including creation of a malicious administrative account, to a single IP address active since at least September 2, 2026: 82.192.72.4. A second address, 103.102.31.18, was observed attempting to exploit the same chain without confirmed success.
CERT Polska also confirmed that upgrading to a patched RouterOS version stops the observed attacks. That is a meaningful, if unsurprising, data point: this is not a case where patching is a precaution against a theoretical future exploit; it is a direct countermeasure against activity happening now.
Independent reporting from the MikroTik user community lines up with CERT Polska's findings. One administrator described, on the MikroTik subreddit, an unauthorized account named "ops" appearing on a device around September 2 at 08:00 UTC, created by another rogue account, with the intrusion traced to the same 82.192.72.4 address CERT Polska identified. Notably, that administrator's team suspected a deeper compromise than RouterOS's own detection could confirm and opted for a full reinstall of the device to be certain it was clean, a useful signal that the built-in detection MikroTik has added should be treated as a helpful indicator, not a guarantee of a clean bill of health.
Latvia's national CERT has also issued its own alert corroborating a marked increase in attacker activity specifically targeting MikroTik routers, independent of CERT Polska's findings.
Indicators of compromise
CERT Polska published the following log entries as signs that MikroTrick has been attempted or used against a device:
login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>
An unexplained, highly privileged account named "ops" is a further indicator worth searching for directly, independent of the log patterns above.
What should you do?
1. Patch immediately
Upgrade RouterOS to one of the fixed releases as soon as possible:
| Branch | Target version |
|---|---|
| RouterOS 6 (legacy) | 6.49.21 or later |
| RouterOS 7 (long-term) | 7.23.5 (not 7.23.4, due to the IPv6 DHCP regression noted above) |
| RouterOS 7 (stable) | 7.24.2 or later |
| RouterOS 7 (development) | 7.25beta3 or later |
Most devices offer an in-place upgrade path through the "Check for Updates" menu in Winbox or WebFig, or via the following from the RouterOS command line:
/system package update check-for-updates
/system package update download
/system reboot
Consult the official MikroTik downloads page if your device is on a channel that requires a manual package transfer.
2. If you cannot patch immediately, reduce exposure now
CERT Polska's interim guidance, until the update is installed, is to disable or restrict the exposed services entirely:
- Disable SSH, WWW/WWW-SSL, and the bandwidth-test server from any address outside a trusted management network, or disable them outright if they are not actively needed.
- Do not use RouterOS's built-in SSH client (
/system sshor/system ssh-exec) or initiate outbound TLS connections from an unpatched device, particularly over untrusted networks or toward untrusted hosts; the affected SSH client and X.509 handling code can be reached in that direction too. - Where remote management is genuinely required, put it behind a VPN, such as WireGuard, rather than exposing management ports directly to the internet.
These are temporary measures that reduce the attack surface. They are not a substitute for installing the patched RouterOS release.
3. Check for signs of prior compromise
After patching, check the system log for a critical entry indicating the device has been marked "Flagged," and run:
/system/device-mode/print
to inspect that status directly. MikroTik's patched releases scan the configuration at startup for known signs of unauthorized changes, disable recognized malicious entries, and set this marker if anything is found.
Do not treat the absence of a Flagged marker as proof the device is clean. Both MikroTik and CERT Polska are explicit that this detection only catches selected, known traces of compromise; it is not exhaustive. Independently of that marker, inspect the configuration for unknown users, scripts, scheduler tasks, proxy servers, and tunnels, and search the log for the indicators listed above.
4. If you find signs of compromise, treat the device as taken over
If the Flagged marker, the logs, or the configuration suggest a device was compromised, CERT Polska recommends the following sequence:
- Isolate the router from the network before doing anything else, and preserve its logs and configuration for later analysis rather than immediately resetting it.
- Restore the device to factory settings and rebuild its configuration from a trusted, verified source. Do not simply restore a full backup taken from the potentially compromised device; that backup may itself contain the compromise.
- Rotate all passwords, keys, and other secrets that were in use on the device.
- Do not clear the Flagged status until the above analysis and evidence preservation is complete.
5. Report confirmed compromise
If you find evidence matching the indicators above, particularly the "ops" account or the specific log entries, CERT Polska recommends reporting it to your national or sector CSIRT alongside your internal incident response process.
A note on how this vulnerability was found
It is worth pausing on the discovery method here, separate from the vulnerability itself. This is one of the more concrete public examples of AI-assisted vulnerability research directly producing a critical, real-world finding in widely deployed network infrastructure, rather than a research paper or a benchmark result. CERT Polska's own framing is measured: the models accelerated hypothesis generation and code analysis inside a carefully constructed lab environment, but every finding still needed to be independently confirmed on real hardware, checked against negative controls, and assessed for impact by human researchers before anything was reported to MikroTik.
That framing matters for how organizations should think about this going forward. The tooling that finds bugs like this is available to defenders and researchers now, which is a genuine positive for coordinated disclosure. It is reasonable to assume similarly capable tooling is, or soon will be, available to less well-intentioned parties as well. The practical takeaway is not that MikroTik's code is unusually flawed; it is that the pace at which vulnerabilities in mature, widely deployed network infrastructure are found is likely to keep increasing, and patch cadence, exposure hygiene, and detection coverage all deserve to be treated as ongoing operational priorities rather than one-time projects.
Summary
| CVEs | CVE-2026-67276 (SSH auth bypass), CVE-2026-86060 (SSH privilege escalation) |
| Nickname | MikroTrick |
| CVSS Score | 9.2 for each of the two chained flaws |
| Type | Unauthenticated remote takeover via SSH authentication bypass and privilege escalation |
| Related flaw | CVE-2026-67277, bandwidth-test memory disclosure/crash (CVSS 8.8) |
| Discovered by | CERT Polska, with AI-assisted research (GPT-5.5-cyber, GPT-5.6-sol) |
| Disclosed | September 5, 2026 (CERT Polska); patches shipped September 3, 2026 |
| Affected | RouterOS 6 below 6.49.21; RouterOS 7 below 7.23.4 and 7.24 below 7.24.2; development branch before 7.25beta3 |
| Exposure condition | SSH (or bandwidth-test/WebFig) reachable from an untrusted network; not the default configuration |
| Estimated internet exposure | Roughly 122,500 devices with SSH reachable from the internet as of September 5, 2026 (Shadowserver); broader MikroTik RouterOS internet exposure across all services runs considerably higher |
| Active exploitation? | Yes, confirmed by CERT Polska since at least September 2, 2026 |
| Known attacker infrastructure | 82.192.72.4 (confirmed successful attacks); 103.102.31.18 (attempted) |
| Immediate mitigation | Restrict or disable SSH, WWW/WWW-SSL, and bandwidth-test from untrusted networks; use a VPN for management access |
| Full fix | Upgrade to RouterOS 6.49.21, 7.23.5, 7.24.2, or 7.25beta3 |
| Detection | Check for "Flagged" status via /system/device-mode/print; search logs for the IoCs above; absence of a Flagged marker does not rule out compromise |
If you need help identifying which of your MikroTik devices have management services exposed to the internet, auditing configurations for signs of compromise, or rolling out patches across a fleet of edge devices, get in touch. An unauthenticated, full-control chain against widely deployed edge infrastructure, already being exploited, is exactly the kind of situation that deserves attention now rather than at the next scheduled maintenance window.