Two **MikroTik RouterOS** SSH vulnerabilities, when chained together, allow attackers to seize full administrative control of internet-exposed routers without requiring a password, SSH key, or completed authentication. **CERT Polska** has named this critical chain **MikroTrick**. It leverages an SSH state-machine flaw (**CVE-2026-67279**) and an argument-injection bug in the **RouterOS** login process (**CVE-2026-86060**). Attack logs indicate exploitation began as early as September 2, a day before **MikroTik** released patches in **RouterOS** versions 6.49.21, 7.23.4, and 7.24.2. **CERT Polska** initially warned about these RouterOS flaws on September 5, confirming active exploitation and urging immediate patching, but did not detail the specific vulnerabilities or their combination. A recent analysis provides the technical specifics of this dangerous chain. ### How the Chain Works SSH typically follows a three-step sequence: establishing an encrypted connection, authenticating the user, and then allowing the client to open a session and execute commands. A successful authentication is confirmed by the server sending an `SSH_MSG_USERAUTH_SUCCESS` message. **CVE-2026-67279** disrupts this sequence. If an SSH client initiates a key renegotiation during the authentication phase, vulnerable **RouterOS** versions skip directly to the command phase once the renegotiation concludes, bypassing user identity verification. While this flaw doesn't grant an authenticated session or privileges on its own, it allows an unauthenticated client to reach a stage that should demand a completed login. **CVE-2026-86060** then escalates this access to full administrative control. **RouterOS** launches a login program (`/nova/bin/login`) that accepts the username and privilege level as command-line arguments from the SSH daemon without prior username validation. A value starting with a hyphen is interpreted as a program option rather than a username. Attackers exploit this by sending `-2` as the username. The login program then treats this as an instruction to read its identity and privilege level from file descriptor 2, which points to the terminal created by the SSH session.  Through the compromised 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 these inputs, opening a fully privileged console. ### Evidence of Pre-Patch Exploitation The **MikroTrick** chain leaves a distinct footprint in device logs: a failed login attempt for the user `-2`. **CERT Polska** notes that logs matching this pattern appeared on the **MikroTik** forum as early as September 2, preceding the availability of patches. The team believes the chain was actively exploited before fixes were released. A diagnostic report on the **MikroTik** forum detailed the attack sequence on one device: a rejected authentication for `-2`, followed by a forced renegotiation, a jump to the channel phase, and an `exec` request attempting to create a fully privileged user named `ops`. The SSH process crashed on this particular device before the command could complete. Other reports confirm the successful creation of the `ops` account on affected devices. In some instances, **CERT Polska** observed diagnostic-file creation followed by data transfers to an attacker IP address, strongly suggesting that configuration data was exfiltrated. It's important to clarify that the **MikroTrick** chain consists of **CVE-2026-67279** combined with **CVE-2026-86060**. Some publications have incorrectly included **CVE-2026-67276**, which **CERT Polska** states is a separate SSH vulnerability allowing an attacker to forge an RSA key to log in as an existing user. This separate flaw requires prior knowledge of the account name and its public key, granting access only to that specific account. **CISA** added **CVE-2026-86060** to its Known Exploited Vulnerabilities catalog on September 10, independently confirming active exploitation of the argument-injection flaw. This attack chain requires the SSH service to be accessible from the attacker's network. **MikroTik** states that its default home configuration does not expose SSH to the internet. However, administrators who have modified firewall rules or manage devices over SSH from untrusted networks face a higher risk. An authoritative count of compromised devices has not yet been published. ### What to Check While patching prevents future attacks, it does not revert changes made by an attacker before the update. After applying patches, administrators should check the 'Flagged' status by running `/system/device-mode/print`. Both **CERT Polska** and **MikroTik** caution that the Flagged mechanism only detects specific traces of compromise, and its absence does not guarantee the device is secure. **CERT Polska** has provided the following indicators observed in successful 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 investigate for any unknown users, scripts, scheduler entries, tunnels, proxies, unexpected `.rif` diagnostic files, or unexplained `fetch` activity. If any of these indicators are present, **CERT Polska** strongly recommends isolating the device, preserving its logs and configuration, performing a factory reset, and rebuilding it from a trusted configuration. All passwords, keys, and other credentials should be immediately changed, and backups from a compromised device should not be restored. **CERT Polska** utilized 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 their research. Every finding was subsequently verified against real **RouterOS** systems.