Hackers Actively Exploiting MikroTik RouterOS MikroTrick Flaws to Take Full Control of Routers

Threat actors are actively exploiting critical vulnerabilities in MikroTik RouterOS, collectively known as MikroTrick, to compromise internet-exposed routers and gain complete administrative control.

The attacks primarily target devices with SSH management access that are exposed to public networks, prompting urgent patching recommendations from MikroTik, CERT Polska, and Latvia’s national CERT.LV.

On September 3, MikroTik issued a security update announcing that RouterOS versions with the necessary fixes are now available through supported channels.

While the vendor indicated that most configurations are not immediately at risk, it strongly urged all users to update their devices. The affected components include the RouterOS SSH server and client, the bandwidth-test service, X.509 certificate processing, and the WebFig management interface.

Critical SSH Attack Chain

CERT Polska identified six RouterOS vulnerabilities during its research, including two critical SSH flaws that can be chained together to enable unauthenticated full device takeover.

The first flaw, tracked as CVE-2026-67276, has a CVSS score of 9.2 and is an SSH authentication bypass issue. RouterOS incorrectly validated RSA public keys during SSH authentication by failing to compare the complete contents of the assigned key.

An attacker who knows a username and the public modulus of that user’s key can construct a different key and authenticate without possessing the legitimate private key, thereby inheriting the permissions assigned to the targeted account.

The second flaw, CVE-2026-86060, also rated 9.2, affects how RouterOS handles specially crafted SSH usernames. By exploiting an improperly processed username that begins with a prohibited character, an attacker can manipulate session privileges and gain full administrator access to the affected RouterOS device.

Combining these flaws creates a significant risk for routers that expose SSH services to the internet. CERT.LV has reported an increase in attacks targeting publicly accessible RouterOS devices in Latvia, in which attackers have successfully exploited this combination of flaws to take control of vulnerable systems.

A third critical issue, CVE-2026-67277, has a CVSS score of 8.8 and affects the RouterOS bandwidth-test service. This vulnerability could allow an unauthenticated connection to reach a state normally reserved for logged-in users.

When combined with separate issues related to uninitialized packet-buffer data disclosure and an integer-underflow condition during size validation, this flaw could expose kernel memory or trigger a remote denial-of-service condition that restarts the router.

Although these vulnerabilities do not independently provide administrative takeover, they increase the attack surface of unpatched RouterOS deployments.

MikroTik has released fixes in RouterOS versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. The company stated that updated devices will automatically check configurations for known indicators of compromise during startup.

Patched RouterOS versions can assign a device a “Flagged” status if they detect known suspicious configuration modifications. This mechanism disables identified malicious entries, logs a critical event, and activates the Flagged warning.

However, MikroTik and CERT.LV emphasized that a router not marked as Flagged should not be considered definitively safe.

Indicators of compromise may include the following log messages:

• “login failure for user -2 from via ssh”
• “user added by ssh:-2@”
• A highly privileged account named “ops”

CERT Polska has linked successful exploitation activities, including the creation of the “ops” account, to IP address 82.192.72.4. Another address, 103.102.31.18, has been observed attempting to exploit the attack chain.

Administrators should promptly update RouterOS and inspect devices for unauthorized users, scripts, scheduled tasks, proxies, tunnels, and other configuration changes. The Flagged state can be checked using the command: `/system/device-mode/print`.

Organizations unable to patch immediately should restrict public access to SSH, WWW/WWW-SSL, and bandwidth-test services, or restrict access to trusted administrative networks only. They should also avoid using the embedded SSH client or initiating TLS connections from unpatched devices over untrusted networks.

If a compromise is suspected, administrators should isolate the router, preserve logs and configuration evidence, generate a Supout.rif diagnostic file, reset the device to factory defaults, and rebuild it from a trusted configuration.

Additionally, all passwords, keys, and secrets should be rotated. Administrators should not restore a full backup from a potentially compromised router.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.