CVE-2026-86060 — MikroTik RouterOS SSH Pre-Authentication Privilege Escalation to Full Administrative Control

Summary

An unauthenticated remote attacker can obtain full administrative control of a vulnerable MikroTik RouterOS device by interacting solely with its SSH service. No credentials, no user interaction and no local access are required.

Once full policy is obtained, an attacker has the same privileges as a full-group RouterOS administrator: reading and modifying the entire configuration, creating privileged accounts and backdoors, enabling/disabling services, redirecting or intercepting traffic, and using the device as a foothold to pivot into internal networks.

Affected versions

• Vulnerable: RouterOS 6.x and 7.0.0 through 7.23.3 (the whole 6.x and 7.x branches up to the fix).
• Fixed: RouterOS 7.23.4 and newer.

The issue was validated against the official CHR 6.49.20 and CHR 7.21.5 releases running in a local QEMU-based lab (MikroTik Cloud Hosted Router), and additionally confirmed against a small number of internet-exposed installations reached during limited validation research (details withheld; no publication of third-party hosts).

Technical description

The vulnerability is a pre-authentication privilege escalation in the RouterOS SSH service that allows an unauthenticated SSH client to reach a RouterOS console session with a full administrative policy mask.

The specific mechanism, affected code paths and any trigger values are intentionally withheld to prevent reproduction. Only the high-level effect is described: an unauthenticated client can obtain full administrative policy without valid credentials.

Responsible disclosure note: this document intentionally does not publish exploit code, the specific trigger values, or a step-by-step reproduction recipe. Proof-of-concept screenshots are provided (see below); no working payload or source code is released.

Impact

A successful attack gives the unauthenticated remote attacker full full-group administrative privileges on the router. Observed and realistic consequences:

• Complete configuration read/write — dump BGP/OSPF peers, firewall rules, VPN credentials, RADIUS/PPP secrets, certificates.
• Account manipulation — create new full-group users and backdoors, lock out legitimate administrators.
• Service abuse — enable/disable services, open firewall holes, proxy traffic.
• Traffic interception / redirection — DNS hijacking, MITM on routed traffic, redirecting management or user traffic.
• Lateral movement — using the router as a pivot point into the networks it routes, and recovering credentials usable elsewhere on the network.
• Botnet / DDoS material — routers with full control are frequently recruited into DDoS and scanning botnets.

Because RouterOS devices sit at the network edge (gateways, VPN concentrators, ISP CPE, enterprise routers), the blast radius is typically much larger than a single compromised host.

Proof of concept

To keep this advisory safe for public distribution, no exploit code, no trigger values, and no reproduction script are published here.

• Laboratory validation: confirmed on MikroTik CHR 6.49.20 and 7.21.5 in a local QEMU/Docker lab. The proof demonstrated a write action (creation and subsequent removal of a full-policy user) that is impossible for a read-only/unauthenticated session — full admin policy was gained pre-auth.

• Proof-of-concept screenshots:

  

  

Fix

Upgrade RouterOS

The issue is fixed in RouterOS 7.23.4 and later.

1. Back up your configuration first:

   root@kitploit:~

   /system backup save name=backup-before-upgrade
   /export file=export-before-upgrade
   

2. Upgrade via the normal channels:

   • Winbox / WebFig: System → Packages → Check for updates (or upload the routeros-<version>.npk for the router's architecture).
   • CLI: see the manual at https://help.mikrotik.com/docs/spaces/ROS/pages/47579159/Upgrade.

3. After upgrade, verify the running version:

   root@kitploit:~

   /system resource print
   

4. Only then consider re-enabling SSH on external interfaces (see below).

Prefer patching to workarounds. Version updates are the only complete fix. The workarounds below reduce exposure but do not remove the underlying flaw.

Prevention and hardening

For devices that cannot be upgraded immediately — and as defense-in-depth for patched ones:

1. Restrict SSH exposure at the firewall. Do not expose SSH to the Internet or untrusted networks. Allow only trusted source addresses:

   root@kitploit:~

   /ip firewall filter
   add chain=input protocol=tcp dst-port=22 src-address=192.168.1.0/24 \
       action=accept place-before=1
   add chain=input protocol=tcp dst-port=22 action=drop place-before=2
   

2. Disable SSH entirely where it is not required. Winbox, WebFig and the API are often sufficient for management; consider whether remote CLI access must be exposed at all:

   root@kitploit:~

   /ip service disable ssh
   

3. Require strong authentication. If SSH must remain enabled:

   • Use SSH key-based authentication and disable password auth where possible: /user ssh-keys import user=<admin> public-key-file=<file>.
   • Never use blank or default passwords (notably the default admin account).
   • Enforce strong passwords and rotate them regularly.

4. Put management behind a VPN / segmented management network. Route management access through a trusted network or VPN rather than direct exposure; this applies to SSH, Winbox (8291), WebFig/HTTP (80/443), the RouterOS API (8728/8729) and any custom SSH ports (3333, 2222, 8022, and other common re-pins are frequently used).

5. Monitor for indicators of compromise (see Detection below) and enable logging of authentication and configuration events.

6. Keep firmware current and subscribe to MikroTik security advisories: https://mikrotik.com/support/security.

Detection

Signs that this vulnerability may have been attempted or exploited on a device:

• Unexpected configuration changes: new users (especially with full group), new firewall rules opening access, changed services, unexpected backdoor accounts.
• New or modified /system identity, DNS settings, or routing/firewall rules you did not make.
• Unusual SSH activity in router logs, such as repeated authentication failures or sessions opened without a corresponding successful login event.

Useful checks on a running device:

# list users and look for accounts you did not create
/user print detail

# check the log for unusual SSH activity
/log print where topics~"ssh"

Disclaimer

This document is published for defensive and educational purposes — to allow administrators of MikroTik devices to assess exposure, verify patching status, and harden their deployments. Exploitation details are intentionally withheld, and no working exploit is released. Test only systems you own or are authorized to assess.