MikroTrick: Two RouterOS Flaws Let Attackers Take Over Exposed MikroTik Routers

A chain of vulnerabilities in MikroTik's RouterOS lets an attacker with nothing more than network access to a router's SSH service take the device over completely, and the exploit is no longer theoretical. CERT Polska, Poland's national computer security incident response team, found six flaws in RouterOS, coordinated their disclosure with MikroTik, and confirmed on 5 September that two of them are being combined in live attacks. The team gave the chain a name: MikroTrick.

Related reading: AI-Found Rejetto HFS Authentication Bypass Draws Exploitation Attempts · Google Patches CVE-2026-58704, an Actively Exploited Pixel Modem Zero-Day.

Both bugs at the centre of the chain carry a CVSS score of 9.2. MikroTik shipped fixes ahead of the public disclosure, first in RouterOS versions 6.49.21, 7.23.4 and 7.24.2 on 3 September, plus the 7.25beta3 build. CISA added the two RouterOS flaws to its Known Exploited Vulnerabilities catalog on 10 September, giving federal civilian agencies until 13 September to patch or document compensating controls. The same batch covered ConnectWise ScreenConnect and JFrog Artifactory.

The scale of the target set is the part that should stop a reader short. The Shadowserver Foundation counted about 122,500 MikroTik devices with SSH reachable from the internet in a single 24-hour scan window on 5 September. That figure is not a count of vulnerable devices, because no version check was performed. It is a count of devices that were answering on the port the attack chain needs.

What the two flaws do

The first half of MikroTrick, tracked as CVE-2026-67276, is an authentication bypass in RouterOS's SSH server. When validating a user's RSA public key, RouterOS compared only part of the key: its type and public modulus. It did not compare the full key, so it ignored the public exponent.

The distinction sounds academic until you consider what it permits. An attacker who knows a username and the modulus of that user's authorized key can construct a different key pair that shares the modulus, set its public exponent to 1, and produce a signature RouterOS accepts. No private key is required, because the server never checked the part of the key that would have made forgery impossible.

The second half, CVE-2026-86060, upgrades whatever foothold the bypass provides into full administrative control. RouterOS mishandled SSH usernames that began with a character it should have rejected. A crafted value such as -2 reached a legacy login helper that read the leading hyphen as the start of a command-line flag rather than as a literal username. By supplying a username shaped that way, an attacker could alter the router's trusted policy mask and end up with a fully privileged session.

Neither flaw requires a password, a valid account, or any interaction from the device's owner. The pair only needs SSH to be reachable, which is exactly how many administrators leave it so they can manage a router that sits somewhere awkward.

A third flaw, and three more

CERT Polska disclosed six issues in total. The third most serious is CVE-2026-67277, a missing-authentication flaw in the bandwidth-test, or btest, service. An unauthenticated connection could enter a state reserved for logged-in users. Combined with a leak of uninitialized data from a kernel packet buffer and an integer underflow in the size check, this can expose kernel memory or crash the device into a restart.

Three lower-severity flaws round out the set: an issue in the SSH client, a signature-validation weakness in X.509 certificate handling, and an information-disclosure bug in the WebFig interface. None of them is part of the observed takeover chain, but they widen the surface administrators have to reason about.

The traces the attackers left

CERT Polska tied the confirmed compromise to concrete artifacts. RouterOS logs from attacked devices contain entries resembling a login failure for user -2, followed by a user addition attributed to ssh:-2@ and the attacker's address. The agency also flagged an unexplained highly privileged account named ops as a sign of successful exploitation.

The attacks it could confirm, including creation of that ops account, came from 82.192.72.4, an address in a Leaseweb range, active since at least 2 September, three days before the public advisory. A second address, 103.102.31.18, was used in exploitation attempts. The payload observed on compromised systems was a MIPS-architecture BusyBox binary closely resembling a 2010-era official BusyBox release, shipped alongside Python and shell scripts, according to the Cloud Security Alliance's research note. Reusing a decade-old, publicly available tool rather than purpose-built malware points to speed over stealth, consistent with internet-wide scanning rather than a hand-picked target list.

The timing is uncomfortable. Exploitation was underway by 2 September. MikroTik shipped fixes on 3 September. Public disclosure arrived on 5 September. For several days, a working unauthenticated takeover existed against devices that had no CVE number to search for and no advisory to read.

Why edge and management gear keeps drawing fire

RouterOS is a fixture at the network edge. Internet service providers, small and mid-sized businesses, and network enthusiasts run it because the hardware is inexpensive and the configuration options are deep. Those same qualities make the devices attractive: they sit on the perimeter, they are trusted by everything behind them, and they are often installed once and then left alone.

That combination has played out before. A 2023 Censys survey cited by the CSA note counted nearly 450,000 hosts still exposing vulnerable RouterOS configuration interfaces months after an earlier critical patch. Devices that nobody logs into are also devices that nobody patches on a schedule, which stretches the window in which a known flaw remains useful to an attacker.

The comparison with the GitLab and Artifactory stories from the same weeks is instructive. In each case the vulnerable software sat inside the perimeter, holding credentials or controlling traffic, and was patched on a slower cycle than the internet-facing applications that tend to get more attention. Management planes are trusted by design. An attacker who reaches one inherits a great deal of that trust.

The caveats worth keeping

MikroTrick's authentication bypass is severe, and its practical reach is narrower than the CVSS score alone suggests. The forged key has to share a modulus with a real authorized key, which means the attacker needs to know that modulus. Keys reused across a fleet of devices, published by accident, or generated with weak parameters make that easier. The CSA note reports that the technique reproduced reliably against RSA keys generated with a low public exponent, while keys using the common exponent 65537 were not uniformly susceptible. Organisations should read that as a reason to inventory and regenerate the SSH keys authorized on RouterOS devices, and as a reason not to assume every exposed router is trivially exploitable.

The second caveat concerns the vendor's compromise check. RouterOS now scans its configuration at startup, disables recognised suspicious entries, writes a critical log message, and marks the device as Flagged. CERT Polska is explicit that this mechanism detects only selected traces. The absence of the marker is not evidence that a device is clean. Administrators should treat the flag as one signal among several, not as a clean bill of health.

What administrators should do now

CERT Polska's guidance is direct, and the order matters.

• Upgrade RouterOS immediately to 6.49.21, 7.23.4, 7.24.2, or the 7.25beta3 build. Patch first; the rest is triage.
• If an immediate upgrade is impossible, disable SSH, WWW/WWW-SSL and the bandwidth-test server, or restrict each to trusted management networks. Avoid initiating TLS connections from an unpatched device or using its built-in SSH client against untrusted hosts.
• Check the output of /system/device-mode/print for the Flagged marker, and review /system history and the user list for the -2 artifact, an unexpected ops account, or other unfamiliar logins.
• Inspect the configuration for unknown users, scripts, scheduler tasks, proxy servers and tunnels.
• Treat a device with the Flagged marker, unexplained configuration changes, or unrecognised scripts as compromised. Isolate it, preserve its logs and configuration, rebuild from a known-good configuration, and rotate passwords, keys and other secrets. Do not blindly restore a full backup taken from a suspect device.

What to watch

The immediate question is adoption. The fixes are available and the exploitation is documented, but the population at risk is large and slow to move. Shadowserver's count suggests the number of devices with SSH open is in the hundreds of thousands, and the CISA deadline applies only to federal agencies. Evidence of compromise is likely to lag the patching, because a device rebuilt in place without inspection can carry an intruder forward.

A second thread worth following is how the flaws were found. CERT Polska credits Sławomir Rozbicki and the GPT-5.5-cyber and GPT-5.6-sol models, used inside an agent-based lab under researcher supervision, for surfacing the bugs. If model-assisted research keeps finding chains like this in edge firmware, the pressure on vendors to shorten the gap between a private fix and usable public guidance will grow, not shrink.

Cover image: "MikroTIK hAP Lite and RouterBOARD 750" by Stacatto, Wikimedia Commons, CC BY-SA 4.0.