CVE-2026-67279

What is MikroTik RouterOS?

RouterOS is the operating system on MikroTik's routers, switches, and wireless access points. Low prices and an unusually deep feature set have given it an enormous installed base among internet service providers, small businesses, and home labs. The same qualities make it a recurring target: the devices are frequently internet-facing, they are often deployed once and never patched, and a compromised router yields a stable network foothold plus a piece of infrastructure that can be resold as a proxy node. Botnets such as Meris and the Glupteba proxy network were built largely on unpatched RouterOS.

Overview

CVE-2026-67279 is a flaw in the RouterOS SSH server's protocol state machine, classified as CWE-841, improper enforcement of behavioral workflow. The SSH server transitions into the connection protocol after a client-requested rekey even though the client never attempted user authentication. An unauthenticated client can therefore open a session channel and send an exec request, and the server dispatches the command.

On its own the bug carries a moderate rating, CVSS 3.1 6.5 in the NVD entry and 6.9 as scored by MikroTik, because the reachable command surface is limited rather than a general shell. What it does give an unauthenticated attacker is the ability to create, overwrite, and reconstruct files in the RouterOS managed file namespace, including support files that bundle configuration and diagnostic data. That is both a disclosure path for sensitive configuration and a write primitive.

Its importance is as an entry point. CISA's KEV entry states that CVE-2026-67279 can be chained to achieve unauthenticated exploitation of CVE-2026-86060, the argument-delimiter injection that promotes an SSH session to full administrative policy. That combination turns a medium-severity state-machine bug into unauthenticated administrative takeover of any RouterOS device with SSH reachable. CISA added it to the KEV catalog on September 25, 2026, roughly two weeks after CVE-2026-86060 was listed, with a deadline of September 28, 2026.

Affected Versions

MikroTik shipped the fixed builds on September 3, 2026.

Technical Details

SSH is a layered protocol. The transport layer negotiates keys, the authentication layer establishes who the client is, and only then does the connection layer allow channels, exec requests, and shell sessions. A correct server refuses to service connection-layer requests until authentication has succeeded.

RouterOS did not track that ordering correctly across a rekey. Rekeying is a normal transport-layer operation in which either side can renegotiate session keys mid-connection, and the specification permits a client to initiate it. In the affected builds, completing a client-requested rekey left the server believing it had progressed past the authentication phase, even when no SSH_MSG_USERAUTH_REQUEST had ever been sent. This is what CWE-841 describes in plain terms: the code did not enforce the order its own workflow requires, so a step could be skipped by taking a side path.

Attack characteristics: network reachable, low complexity, no authentication, no user interaction (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). It is a single-connection primitive with no user interaction required, and it needs nothing more than TCP access to the SSH service.

CERT Polska's disclosure covered six RouterOS CVEs, including CVE-2026-67276 (an SSH public-key authentication bypass in which RouterOS compares key type and modulus but never the exponent), CVE-2026-67277 (btest kernel memory disclosure and denial of service), CVE-2026-67278, CVE-2026-67281, and CVE-2026-86060. Sources describe the MikroTrick chain slightly differently: some pair CVE-2026-67276 with CVE-2026-86060 as the primary route and treat CVE-2026-67279 as a separate finding, while CISA's KEV entry explicitly names CVE-2026-67279 as a chain partner for CVE-2026-86060. Both pre-auth bugs reach the same privilege escalation, and both are fixed in the same builds, so the practical guidance does not change.

Discovery

The vulnerability was discovered and reported by Slawomir Rozbicki of CERT Polska (CERT.pl), as part of the coordinated six-CVE RouterOS disclosure published on September 7, 2026. CERT Polska coined the name MikroTrick for the SSH takeover chain. MikroTik credits CERT.pl in its September 2026 advisory.

Exploitation Context

CERT Polska confirmed that attackers are actively exploiting the RouterOS SSH chain to take full administrative control of devices with SSH exposed to the internet, with the earliest observed activity on September 2, 2026, one day before MikroTik released fixes. Shadowserver counted roughly 122,500 MikroTik devices with publicly reachable SSH on September 5, 2026; how many of those were unpatched or already compromised is not established.

The published indicators come from the chain as a whole rather than this CVE in isolation. Look for SSH login attempts using the username -2, an unexpected ops user account on the device, and connections from 82.192.72.4 and 103.102.31.18. A proof of concept for the public-key bypass half of the chain has been published on GitHub, so exploitation is not limited to the original operators. No specific threat actor has been attributed, and the KEV entry records no known ransomware use.

Remediation

1. Upgrade RouterOS to the fixed build for your train: 6.49.21, 7.23.4, 7.24.2, or 7.25 beta 3. Federal agencies are required to complete this by September 28, 2026.
2. Take SSH off untrusted networks. MikroTik's own advice is explicit: restrict the SSH service to trusted management addresses with firewall rules, or remove it from public interfaces entirely and reach the device over a VPN such as WireGuard. This is the single control that defeats the whole chain.
3. Check whether the device is flagged. MikroTik's advisory describes a "Flagged" status in the device logs that indicates compromise, with documented remediation steps to follow if it appears.
4. Look for the chain indicators. Review the user list for an account named -2 or ops, or any account you did not create. Check logs for SSH sessions that opened channels without a preceding successful login, and for connections from the reported attacker addresses.
5. Inspect the configuration after upgrading. Attackers with administrative access add scripts, schedulers, SOCKS and proxy settings, NAT and firewall rules, and additional users. Compare the running configuration against a known-good baseline rather than skimming it.
6. Assume compromise if SSH was exposed before patching. Reset to a known-good configuration, rotate every credential on the device, and re-examine what else that device could reach on the internal network.