Cybersecurity

Active Exploitation of RouterOS Vulnerabilities Enables Full Control of MikroTik Devices

Attackers are attempting to exploit a chain of two critical vulnerabilities in MikroTik RouterOS to bypass SSH authentication and then obtain full administrative privileges, amid warnings of active attacks against devices exposed to the internet. MikroTik has released security updates, while Poland’s CERT recommended isolating devices suspected of compromise and rebuilding them from trusted configurations.

2026-09-07
4 min read
11 views
فريق تحرير certi.news
Active Exploitation of RouterOS Vulnerabilities Enables Full Control of MikroTik Devices

Attackers are attempting to take control of MikroTik routers that expose the SSH service to the internet, using a chain of two recent vulnerabilities in RouterOS. According to a warning from Poland’s CERT, the attacks are actively underway and target devices accessible from public networks.

The Exploit Chain Grants the Attacker Administrative Privileges

The first vulnerability, tracked as CVE-2026-67276, involves an SSH authentication bypass resulting from incomplete verification of public RSA keys. The attacker needs to know a username and the public modulus parameter of that user’s key, after which they can create a different key and log in without possessing the legitimate private key.

The second vulnerability, CVE-2026-86060, is an SSH privilege-escalation vulnerability caused by improper handling of specially crafted usernames. Using a modified username, the attacker can manipulate the SSH session and gain full administrative privileges. Poland’s CERT named the exploit chain MikroTrick, noting that both vulnerabilities are classified as critical in severity.

Poland’s CERT discovered the vulnerabilities with assistance from GPT-5.5-cyber and GPT-5.6-sol. The organization also identified a third vulnerability, CVE-2026-67277, affecting the bandwidth-test service and allowing an unauthenticated attacker to leak contents from kernel memory or remotely cause the router to crash or reboot.

Updates and Affected Versions

MikroTik fixed the vulnerabilities in RouterOS 7.25beta3, 7.24.2, 7.23.4, and 6.49.21, released on September 3. Poland’s CERT reviewed the fixes, but the company explained that only certain configurations are affected and did not publish additional details to give users time to install the updates.

The new versions add a mechanism for detecting compromise that searches at startup for known indicators of unauthorized configuration changes, then disables malicious entries and logs a critical warning. However, CERT emphasizes that the absence of this indicator does not prove that a device is safe or rule out the possibility that it has been compromised.

Indicators of Compromise and Response Steps

The indicators shared by CERT include logs such as login failure for user -2 from <ip> via ssh and user <name> added by ssh:-2@<ip>, as well as the presence of a highly privileged account named ops. The organization linked the address 82.192.72.4 to confirmed successful attacks, while it observed the address 103.102.31.18 attempting to exploit MikroTrick.

When compromise is suspected, CERT recommends isolating the router, preserving logs and configurations, then resetting the device to factory settings and rebuilding it from a trusted configuration, while changing passwords, keys, and all related secrets. Until updates are installed, SSH, WWW, WWW-SSL, and the bandwidth-test service exposed externally should be restricted or disabled, and the use of built-in SSH clients and outbound TLS connections over untrusted networks should be avoided.

Why Does This Matter?

Data from the ShadowServer Foundation on September 5 provided an indication of the size of the exposure, counting 122,500 MikroTik devices with an exposed SSH interface. The data does not identify how many devices were actually affected by the exploitation, but the combination of authentication bypass and privilege escalation makes simply exposing SSH to the internet a practical risk, especially because taking control does not require the legitimate private key. Therefore, the new detection mechanism should not be considered a substitute for updating or conducting forensic investigations on devices that may have been attacked.

News source
BleepingComputer
Open original source ↗
ف
Author

فريق تحرير certi.news

In the same category

You may also like

View all news