# MikroTrick: Two SSH Bugs Chained into Passwordless Admin on RouterOS

## Summary

MikroTrick is CERT Polska's name for a two-vulnerability chain in RouterOS that gives an attacker **full access to the administrative console with no password and no SSH key**.

Two things make this worse than an ordinary patch cycle:

*   **Exploitation preceded the patch.** The earliest attack logs are dated 02/09/2026; the fix shipped on 03/09. There was no safe window for anyone slow to update.
    
*   **SSH keys and strong crypto settings do not help.** The flaw sits in the SSH state machine, before authentication completes. CERT Polska confirmed successful attacks against devices using only SSH keys with `strong-crypto` enabled. A Shadowserver scan on 05/09 found more than **122,500 MikroTik devices with SSH exposed to the internet**.
    

**Priority actions:**

*   Update RouterOS now, and if you cannot patch yet, block SSH from the internet first.
    
*   Audit accounts across every MikroTik device: look for an `ops` account in the `full` group and any user not on your known list.
    

## Affected and Fixed Versions

MikroTik released fixes on **03/09/2026**. Everything prior to these versions is affected:

| Branch | Fixed version |
| --- | --- |
| Testing/beta | 7.25beta3 |
| Stable 7.24 | 7.24.2 |
| Stable 7.23 | 7.23.4 |
| Long-term 6.x | 6.49.21 |

Two CVEs from the chain were added to CISA's Known Exploited Vulnerabilities catalog on **10/09/2026**, with a remediation deadline of just **three days** for US federal agencies — a measure of how CISA rated the severity.

## Flaw One: Rekey During Authentication (CVE-2026-67279)

SSH lets a client and server renegotiate session keys (rekey) mid-session. The problem is that RouterOS mishandles a rekey initiated **while user authentication is still incomplete**.

Instead of resuming the interrupted authentication, the server **moves straight from the temporary rekey state into channel handling**. In effect, it behaves as if authentication had completed when it never did.

The result is that an unauthenticated client can open a session channel. That is not admin access yet, but it is the doorway the second flaw needs.

## Flaw Two: Policy Mask Injection via the Username (CVE-2026-86060)

In SSH, the username is sent in `SSH_MSG_USERAUTH_REQUEST` **before authentication finishes**. RouterOS's `sshd` stores that value and passes it on, unvalidated, as an element of the `argv` array handed to `/nova/bin/login`.

The catch: a username starting with `-` is not read by `login` as a name but as a **command-line argument**. Specifically, the username `-2` makes `login` read the policy mask — the session's permission set — from file descriptor 2, which is the pseudoterminal attached to the SSH channel the attacker controls.

![](https://cdn.hashnode.com/uploads/covers/676511773cdd3c06f7b226ee/1bc17c56-d151-4f8e-8e62-5ca0cd16e35c.png align="center")

![Username validation function after the fix](https://cert.pl/en/uploads/2026/09/mikrotrick-validlogin.png align="center")

The attacker therefore supplies their own policy mask, including full administrative rights. The patch adds username validation that rejects any value beginning with a hyphen or a space.

## The Full Exploit Chain

1.  **Connect over SSH and send** `SSH_MSG_USERAUTH_REQUEST` **with the username** `-2`**.** The attempt is rejected, but `sshd` has already stored the username.
    
2.  **Initiate a rekey while still in the authentication phase.** CVE-2026-67279 makes the server jump to channel handling once the rekey completes.
    
3.  **Open a session channel without authenticating**, then send policy mask data over that channel.
    
4.  `login` **reads the policy mask from file descriptor 2** and grants a full-admin session. From there the attacker sends an `exec request` to run commands on the admin console. CERT Polska describes the trace on one real device: a rejected authentication for user `-2`, a forced renegotiation, a jump to the channel phase, and an `exec request` creating a user called `ops` with full privileges.
    

## What the Attackers Did on Real Devices

Per CERT Polska, the observed actions were:

*   **Creating an** `ops` **account** in the `full` group, the highest privilege level. That is a backdoor for returning even after the device is patched.
    
*   **Generating an RIF diagnostic file** and using the `fetch` command to send it to attacker infrastructure at `82.192.72.4`. RouterOS diagnostic files contain configuration and system information, making this an environment-reconnaissance step. One administrator reported finding the backdoor account across **multiple devices under their management**, which points to broad automated exploitation rather than individually selected targets.
    

CERT Polska **does not describe what the compromised devices were used for afterwards**, and neither do the two Hacker News reports. At this point there is no basis for concluding this is a botnet, proxy, or traffic-interception campaign.

## Timeline

| Date | Event |
| --- | --- |
| 02/09/2026 | Earliest publicly reported attack logs, one day before the patch |
| 03/09/2026 | MikroTik releases fixes |
| 02–05/09/2026 | Exploitation reports appear on the MikroTik forum and Reddit |
| 05/09/2026 | CVEs published (20:00:55 UTC); Shadowserver runs its exposure scan |
| 10/09/2026 | CISA adds the issues to KEV with a 3-day deadline |
| 22/09/2026 | CERT Polska publishes the full technical analysis |

## Exposure

In a 24-hour scan on 05/09, the Shadowserver Foundation found over **122,500 MikroTik devices with SSH reachable from the public internet**. The most affected countries:

| Country | Devices |
| --- | --- |
| Brazil | ~11,300 |
| United States | ~7,100 |
| Indonesia | ~7,100 |
| Czech Republic | ~6,300 |
| Ukraine | ~5,100 |

These are devices with **SSH exposed**, not devices confirmed compromised, and the count does not separate patched from unpatched. It does show the size of the available attack surface when the flaws went public.

## Indicators of Compromise

Work through these on every MikroTik device:

**In system logs**

```plaintext
login failure for user -2        # clearest trace of the chain
ssh:-2@                          # appears in user-creation entries
user ops added by ssh            # the backdoor account being created
```

**In configuration**

*   An `ops` account in the `full` group, or any user not on your known list
    
*   Scripts, schedulers and configuration changes of unknown origin
    
*   Traces of an RIF diagnostic file created and then exfiltrated **After updating**
    
*   Patched RouterOS adds a `Flagged` mechanism that warns when suspicious configuration — such as the creation of an `ops` account — is detected. Check this status right after patching. **Observed attacker IPs**
    

```plaintext
82.192.72.4       # exfiltration destination for diagnostic files
103.102.31.18     # observed attacking IP
```

These two IPs are only what was observed, not a complete list. Their absence from your logs does not mean a device is clean; the `user -2` trace is the more reliable indicator.

## Analysis

**There was no safe window.** Exploitation began a day before the patch. For edge devices, that means assuming any device with SSH exposed in early September may have been touched, and hunting for traces rather than treating the update as closure.

**Hardened authentication does not save you from a state-machine bug.** This is the sharpest lesson here. Many organizations believe moving to SSH keys and disabling passwords is enough for network gear. In this case the flaw fires before any authentication mechanism has a say, so configuration hardening cannot stop it. The control that actually works is **limiting who can reach the management port**, not strengthening authentication on it.

**Admin access on a router is a stepping stone, not the destination.** Edge devices can read and route traffic, build tunnels, alter DNS and act as relays. The attackers pulling diagnostic files suggests they wanted to understand the environment, which usually precedes a later stage. Response should therefore consider what passes through the device, not only the device itself.

**The** `ops` **account is a cheap, high-value indicator.** A fixed account name used across broad exploitation is a gift to defenders. If you manage a fleet of MikroTik devices, one pass over the user lists is worth doing immediately, patched or not.

**CERT Polska used AI models to assist automated testing** (GPT-5.5-cyber and GPT-5.6-sol) during the analysis — a notable detail about how CERT organizations are changing their vulnerability research workflow.

## Relevance to Vietnam

*   **MikroTik is widespread in Vietnam.** It is a common choice for small ISPs and residential internet providers, internet cafés, SMEs, and many camera and branch-network deployments. Low cost and configuration flexibility drive that, but patch management is typically less systematic than for major vendors' gear.
    
*   **Exposing SSH or Winbox to the internet for remote administration** is still common, especially where there is no dedicated management VPN.
    
*   **Contractor-installed, then forgotten.** Many routers are configured once by an installer and never firmware-tracked again. This is the highest-risk group for MikroTrick.
    
*   **The 6.x branch is still widely deployed.** Its fix is 6.49.21; plenty of older devices still run unpatched 6.4x builds.
    

## Recommendations

*   **Update RouterOS now** to 7.25beta3, 7.24.2, 7.23.4 or 6.49.21 depending on branch. If maintenance windows constrain you, block SSH from the internet first and patch afterwards.
    
*   **Restrict management services** (SSH, WWW/WWW-SSL, API, Winbox, bandwidth-test) to trusted networks or VPN access only. This is the one control that does not depend on where in the authentication flow the bug sits.
    
*   **Audit the whole fleet, not just suspect devices:** check user lists for `ops` and unknown accounts, review scripts and schedulers, and search logs for `login failure for user -2` and `ssh:-2@`.
    
*   **For compromised devices:** isolate from the network, preserve logs and configuration before resetting, reset to defaults and rebuild the configuration, and rotate every password and secret (PPP, RADIUS, IPsec, SNMP communities) since they were in the attacker's hands.
    
*   **Load the indicators into your SIEM:** IPs `82.192.72.4` and `103.102.31.18`, the log strings above, and the account name `ops`. Also build a rule for new accounts created on network devices — a useful signal well beyond this campaign.
    
*   **Forward network device logs to the SIEM.** RouterOS log storage is limited and rotates; without forwarding, the `user -2` trace from early September may already be gone from the device.
    

## References

*   CERT Polska (Sławomir Rozbicki) — *MikroTrick: technical analysis* (22/09/2026): https://cert.pl/en/posts/2026/09/mikrotrick-technical-analysis/
    
*   The Hacker News (Swati Khandelwal) — *MikroTrick Chain Let Attackers Take Over MikroTik Routers Without a Password or SSH Key* (23/09/2026): https://thehackernews.com/2026/09/mikrotrick-chain-let-attackers-take.html
    
*   The Hacker News (Swati Khandelwal) — *Attackers Hijack MikroTik Routers* (06/09/2026): https://thehackernews.com/2026/09/attackers-hijack-mikrotik-routers.html
    
*   SecurityWeek (Ionut Arghire) — *MikroTik Patches Critical Flaws Chained to Hack Routers* (08/09/2026): https://www.securityweek.com/mikrotik-patches-critical-flaws-chained-to-hack-routers/
    
*   Cybernews — *MikroTik RouterOS vulnerabilities expose 122,500 routers* (07/09/2026): https://cybernews.com/security/mikrotik-routers-under-active-exploitation/
    
*   CISA — Known Exploited Vulnerabilities Catalog (added 10/09/2026)