MikroTik RouterOS flaws CVE-2026-67279 and CVE-2026-86060 gave unauthenticated full admin access

Two RouterOS flaws end in unauthenticated admin access

MikroTik shipped fixes on 3 September 2026 for two RouterOS vulnerabilities that, chained together, hand an unauthenticated remote attacker full administrative control of a router. According to a technical write-up on dev.to, the bugs — CVE-2026-67279 and CVE-2026-86060 — matter most because of where RouterOS devices typically live: on the edge between an organisation and the internet, defining its routing, firewall and VPN posture.

How the chain works

The first flaw sits in SSH session handling. When a key re-exchange happens while authentication is still in progress, RouterOS moves the connection into the channel phase without ever confirming who is on the other end. The second flaw lives in the login helper: a username beginning with a hyphen gets parsed as a command-line option, and the policy mask applied to the session is drawn from the pseudo-terminal the attacker is typing into. Neither bug checks a password or demands a key.

The dev.to analysis highlights three properties that drive its risk assessment: the attack needs no credentials, making it remotely automatable; it lands directly on a management listener, so no prior foothold is required; and it terminates with full privileges rather than a limited primitive that would still need escalation.

Observed exploitation

This is not purely theoretical. The write-up, drawing on public campaign logs and on CERT Polska's analysis of what it calls MikroTrick, reports a privileged operations account created over SSH, along with a device diagnostic file exported to an external address using RouterOS's built-in fetch tool. The export detail suggests the intruder was mapping the environment rather than merely holding it.

Control of an edge router carries downstream consequences a host compromise does not. Routing edits can divert or intercept traffic. Firewall and NAT changes can open paths that were deliberately closed. VPN and IPsec secrets can keep an attacker connected even after the bugs are patched. And attacker-created accounts persist across reboots and upgrades.

Scope and fixed versions

The September 2026 fixes cover RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21. Devices that were reachable from the internet before those releases warrant a post-patch review even if they now run current code.

For sizing, a ZoomEye query of os="RouterOS" && service="ssh" returned 9,559 devices. The analysis is explicit that this counts reachable SSH management listeners — the population that faced a patching decision — and should not be read as a verified tally of vulnerable systems.

Recommended actions

The write-up lays out a remediation sequence for operators:

• Treat RouterOS updates as scheduling-critical and move devices to fixed builds promptly.
• Remove public management reachability where possible, and where it cannot be avoided, restrict it to administrative networks.
• Audit accounts and the firmware's Flagged status after patching.
• Review SSH logs for hyphen-prefixed usernames across the entire exposure window, not only since the update.
• Rotate every secret stored on devices with findings and re-baseline routing and firewall configuration.
• Where the router is a chokepoint for regulated traffic, involve the risk owner before declaring the incident closed.

The dev.to piece also points to CERT Polska's disclosure write-up — which covers the reporting process and its use of LLM agents — alongside MikroTik's September 2026 release notes and the CISA Known Exploited Vulnerabilities catalog as primary references.

Why it matters

Edge routers are trust anchors: whoever controls one controls the path of every packet crossing it. An unauthenticated, automatable path to full admin on that device is a different order of risk from a typical host-level bug, and the observed tradecraft — account creation plus diagnostic export — shows attackers treating it that way. With roughly 9,500 SSH-reachable RouterOS listeners measured and persistence mechanisms designed to outlive the patch, infrastructure teams should treat this as patching plus a forensic sweep: check logs back across the full exposure window, verify accounts, and rotate anything the router stored.