Two MikroTik RouterOS SSH vulnerabilities chained together let attackers take full administrative control of Internet-exposed routers without a password, SSH key, or completed authentication.
The chain, which CERT Polska calls MikroTrick, combines an SSH state-machine flaw (CVE-2026-67279) with an argument-injection bug in the RouterOS login process (CVE-2026-86060). Attack logs date to at least September 2, one day before MikroTik shipped patches in RouterOS 6.49.21, 7.23.4, and 7.24.2.
As previously reported, CERT Polska warned on September 5 that attackers were using RouterOS flaws to take control of devices whose SSH service was reachable from public networks.
That warning confirmed the exploitation and urged immediate patching but did not identify which two flaws formed the chain or explain how they combined. This latest analysis provides both.
How the Chain Works
SSH requires three steps in order: it establishes an encrypted connection, authenticates the user, and only then lets the client open a session and run commands. The server sends a specific message (SSH_MSG_USERAUTH_SUCCESS) to confirm that authentication has passed.
CVE-2026-67279 breaks this sequence. If a client starts an SSH key renegotiation during the authentication step, vulnerable RouterOS moves straight to the command phase when the renegotiation finishes, without ever confirming the user’s identity.
The flaw does not create an authenticated session or grant any privileges on its own, but it allows an unauthenticated client to reach a stage that should require a completed login.
CVE-2026-86060 turns that access into full administrative control. RouterOS launches a login program (/nova/bin/login) that receives the username and a privilege level from the SSH daemon as command-line arguments, without checking the username first. A value beginning with a hyphen is treated as a program option rather than a name.
The attacker sends -2 as the username. The login program treats this as an instruction to read its identity and privilege level from file descriptor 2, which points to the terminal the SSH session created.
Through the SSH channel, the attacker has already written a chosen username and the privilege value for full administrative access to that terminal. The login program accepts both and opens a fully privileged console.
Evidence of Pre-Patch Exploitation
The chain leaves a distinctive trace in device logs: a failed login attempt for user -2. CERT Polska says logs matching this pattern appeared on the MikroTik forum as early as September 2, one day before the patches became available, and the team believes the chain was exploited before MikroTik released the fixes.
A diagnostic report on the MikroTik forum shows the attack sequence on one device: rejected authentication for -2, a forced renegotiation, a jump to the channel phase, and an exec request attempting to create a user called ops with full privileges. The SSH process crashed before the command completed on that device.
Other reports confirmed that the ops account was successfully created on affected devices. In some incidents, CERT Polska found diagnostic-file creation followed by data transfers to an attacker IP address, strongly suggesting that configuration data was copied to the attacker’s infrastructure.
The MikroTrick chain is CVE-2026-67279 combined with CVE-2026-86060. Some publications have incorrectly included a third flaw, CVE-2026-67276, which CERT Polska says is a separate SSH vulnerability that lets an attacker forge an RSA key to log in as an existing user. That flaw requires knowledge of the account name and its public key, and gives access only to that account.
CISA added CVE-2026-86060 to its Known Exploited Vulnerabilities catalog on September 10, independently confirming active exploitation of the argument-injection flaw.
The chain requires SSH to be reachable from the attacker. MikroTik says its default home configuration does not expose SSH to the Internet, but administrators who changed their firewall rules or manage devices over SSH from untrusted networks face higher risk.
No authoritative count of compromised devices has been published.
What to Check
Patching prevents the attack but does not remove changes an attacker made before the update. After updating, administrators should check the Flagged status by running /system/device-mode/print.
The Flagged mechanism detects only selected traces of compromise, and its absence does not prove the device is safe, CERT Polska and MikroTik both say.
CERT Polska published these indicators from observed attacks:
- Username: -2 in SSH login logs
- Account: ops in the full privilege group
- IP: 82.192.72.4 (observed in successful attacks)
- IP: 103.102.31.18 (used in exploitation attempts)
Administrators should also check for unknown users, scripts, scheduler entries, tunnels, proxies, unexpected .rif diagnostic files, or unexplained fetch activity.
If any of these indicators are present, CERT Polska recommends isolating the device, preserving its logs and configuration, factory resetting it, and rebuilding it from a trusted configuration.
All passwords, keys, and other credentials should be changed. A backup from a compromised device should not be restored.
CERT Polska used AI models, including GPT-5.5-cyber and GPT-5.6-sol through the OpenAI GTAC program, alongside locally hosted open-weight models to automate laboratory testing and protocol analysis during the research. Every finding was verified against real RouterOS systems.
The Hacker News has contacted CERT Polska and MikroTik for comment on the technical analysis.
