MikroTrick and the SSH key check that forgot the exponent
In September 2026 CERT Polska published what the community now calls MikroTrick: an SSH-based chain that takes unauthenticated control of MikroTik RouterOS devices. Attackers were already using it before the fixes shipped, and CISA added CVE-2026-86060 to the Known Exploited Vulnerabilities catalog on 10 September 2026.
The defect
RSA signature verification is straightforward arithmetic. A signature s over a message m is valid when s^e mod n reproduces the expected encoding of m, where n is the modulus and e the public exponent. In normal keys e is 65537. If e is 1, then s^1 mod n is just s, which means the signature is the message and nothing needs to be signed at all.
RouterOS, as described in public analysis, matched an authorised SSH key on its type and modulus while ignoring the exponent, and then verified the submitted signature against the client-supplied key rather than the stored one. An attacker who knows a target user's public key can therefore present a key with the same modulus and e=1, and the check passes. Public proof-of-concept code exists for this. A companion flaw, CVE-2026-86060, involves a username that begins with a disallowed character; handling of that value in the SSH login path can alter the trust mask applied to the session, which is how a serial confusion becomes full administrative rights.
What the public record leaves open
Coverage of the pairing has not been consistent. Multiple Chinese-language threat summaries cite the SSH authentication bypass under at least two different identifiers, and the exact internal mechanism for the credential-check flaw has been described both as a signature-verification omission and as a rekey state machine issue. The fix notes and the CVE record for the username-parsing flaw are the reliable anchors. Claims that go further than those documents should be treated as reporting, not as established mechanism.
Temporary mitigation is not especially subtle. If SSH, WebFig and the bandwidth test service do not need to be reachable from the internet, stop exposing them. For routers that do need remote administration, restrict the source address range, because the attack only needs a reachable SSH port.
Detection signals that are specific
Two artefacts appear repeatedly in incident reports and are worth hunting for directly. The first is an SSH login failure for the literal username -2, which the malformed mechanism produces in the log. The second is the creation of an account named ops, a name attackers used after taking control. Patched RouterOS adds a self-check surfaced by /system/device-mode/print, whose Flagged field indicates that the firmware found traces consistent with known tampering.
Those two log patterns are useful precisely because they are narrow. Normal administrative activity does not produce a -2 login. An ops account is not part of a default configuration. Shadowserver's scanning found roughly 122,500 MikroTik devices speaking SSH on the public internet, and reports place the majority of that exposure in Brazil, the United States, Indonesia, Czechia and Ukraine.
Remediation
Upgrade to 6.49.21 on the long-term branch or 7.24.2 on stable; 7.23.4 was also published as a fixed release, and 7.25beta3 appears in the vendor's pre-release channel. Devices that were exposed before patching should be assumed compromised until examined: review local users, authorised SSH keys, schedulers, scripts and firewall rules for entries nobody in the organisation created. Re-flashing with a known configuration may be the cheaper answer when the review is inconclusive, because a router is easy to rebuild and its persistence mechanisms are few.
Top comments (0)