MikroTrick Chain Exploits MikroTik RouterOS Flaws for Unauthenticated Takeover
A chain of two vulnerabilities in MikroTik RouterOS, dubbed MikroTrick, allows unauthenticated attackers to gain full administrative control of internet-exposed routers.
A sophisticated attack chain, identified as MikroTrick by CERT Polska, leverages two critical vulnerabilities in MikroTik's RouterOS to grant unauthenticated attackers complete administrative control over internet-exposed routers. This exploit bypasses traditional authentication mechanisms, including passwords and SSH keys, by chaining an SSH state-machine flaw (CVE-2026-67279) with an argument-injection vulnerability in the login process (CVE-2026-86060).
The exploitation of these flaws has been observed in the wild since at least September 2, predating MikroTik's release of patches in RouterOS versions 6.49.21, 7.23.4, and 7.24.2. While MikroTik addressed the vulnerabilities promptly, the ongoing exploitation highlights the critical need for immediate patching and vigilance.
The attack chain ingeniously disrupts the standard SSH authentication process. Normally, SSH proceeds through connection establishment, user authentication, and then session initiation. However, CVE-2026-67279 allows a client to trigger an SSH key renegotiation during the authentication phase. Upon completion of this renegotiation, vulnerable RouterOS systems incorrectly proceed to the command execution phase without verifying the user's identity, effectively creating a pre-authentication access point.
CVE-2026-86060 then capitalizes on this bypassed authentication. The RouterOS login program, which receives the username and privilege level as command-line arguments from the SSH daemon, fails to validate the username. By sending '-2' as the username, an attacker tricks the login program into reading its identity and privilege level from file descriptor 2, which is linked to the SSH session's terminal. The attacker pre-populates this terminal with a chosen username and the highest privilege level, thereby gaining full administrative access.
Evidence of this exploitation is visible in device logs, which show failed login attempts for the username '-2'. CERT Polska observed these patterns appearing as early as September 2. Diagnostic reports have detailed the attack sequence, including attempts to create an 'ops' user with full privileges. In some confirmed incidents, attackers successfully created the 'ops' account, followed by the creation of diagnostic files and data exfiltration to attacker-controlled IP addresses, indicating potential theft of router configurations.
It is important to note that CVE-2026-67276, another SSH vulnerability affecting RouterOS, is separate from the MikroTrick chain. While CVE-2026-67276 allows an attacker to forge an RSA key to log in as an existing user, it requires prior knowledge of account names and public keys and does not grant the same level of unauthenticated access as the MikroTrick chain. CISA has since added CVE-2026-86060 to its Known Exploited Vulnerabilities catalog, underscoring the active exploitation of this flaw.
The primary prerequisite for this attack is that the SSH service must be accessible from the internet. MikroTik states that its default home configurations do not expose SSH publicly, but administrators who have modified firewall rules or manage devices over SSH from untrusted networks are at significant risk. While no definitive count of compromised devices is available, the widespread nature of MikroTik routers suggests a potentially large attack surface.
To mitigate the risk and detect potential compromises, administrators are advised to update their RouterOS immediately. Post-update, it is crucial to check for signs of compromise, such as the presence of the 'ops' user, unknown scripts, scheduler entries, or unexplained network activity. If indicators are found, isolating the device, preserving logs, performing a factory reset, and rebuilding from a trusted configuration is recommended. All credentials should be reset, and backups from compromised devices should not be restored.