Security News Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended

[Brahman]

Content source

https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/

Identified vulnerabilities​

In the course of our research we identified six vulnerabilities in RouterOS; below we describe the three most important ones, and all of them can be found on a dedicated page.

CVE-2026-67276 - SSH authentication bypass (CVSS: 9.2)​

RouterOS did not properly verify public keys used for SSH authentication - in particular, it did not compare the entire RSA public key assigned to a user. An attacker who knew the username and the public modulus of the user's key could craft a different key and log in via SSH without possessing the corresponding private key. The privileges obtained were equivalent to those of the targeted account.

CVE-2026-86060 - SSH session privilege manipulation via a crafted username (CVSS: 9.2)​

RouterOS did not properly handle usernames beginning with a disallowed character in the SSH login mechanism. By using a crafted username, an attacker could elevate their privileges. The resulting session had full administrative privileges in the RouterOS system.

CVE-2026-67277 - memory disclosure and crash via bandwidth-test (CVSS: 8.8)​

The bandwidth-test service allowed an unauthenticated connection to enter a state that should only be reachable after logging in. Combined with two separate flaws - disclosure of uninitialized data from the packet buffer and an integer underflow in size validation - this enabled kernel memory leakage or a remote DoS attack leading to a system restart.

Recommendations​

We recommend updating RouterOS immediately to one of the versions containing the fixes: 7.25beta3, 7.24.2, 7.23.4, or 6.49.21. After updating, check the logs for the device compromise message and the value of the flagged marker in the output of the /system/device-mode/print command. Also verify the configuration for unknown users, scripts, and other unrecognized changes. The inspection and further steps should follow MikroTik's security bulletin and the Flagged documentation referenced therein. The absence of the marker does not rule out an earlier compromise.

If the patch cannot be installed immediately, do the following until the update is applied:

• Disable the exposed services or block access to them from all addresses outside trusted management networks. This applies in particular to SSH, WWW/WWW-SSL, and the bandwidth-test server;
• Do not initiate TLS connections from an unpatched device or use the built-in SSH clients (/system ssh and /system ssh-exec), especially when communication passes through untrusted networks or is directed at untrusted hosts.

What was actually fixed in the new update?​

The affected versions are:​

RouterOS 7.24 / 7.24.1 → fixed in 7.24.2
RouterOS 7.0–7.23.3 → fixed in 7.23.4
RouterOS 6.x → fixed in 6.49.21

 

[Bot]

What was actually fixed in the new update?​

The affected versions are:​

RouterOS 7.24 / 7.24.1 → fixed in 7.24.2
RouterOS 7.0–7.23.3 → fixed in 7.23.4
RouterOS 6.x → fixed in 6.49.21

The thread shares a CERT.PL-style advisory describing high-severity RouterOS SSH and bandwidth-test issues and urging an immediate upgrade. I cannot independently verify those CVE IDs, CVSS scores, or active exploitation from the supplied evidence, so treat the quoted research as a member-posted claim and follow MikroTik’s own bulletin for the official fix list.

What this means
Brahman posted three highlighted issues: an SSH public-key check that allegedly did not compare the full RSA key (CVE-2026-67276), SSH privilege elevation via a crafted username (CVE-2026-86060), and unauthenticated bandwidth-test memory disclosure or crash (CVE-2026-67277). The same post lists patched builds as 7.25beta3, 7.24.2, 7.23.4, and 6.49.21, and maps 7.24/7.24.1 to 7.24.2, 7.0–7.23.3 to 7.23.4, and 6.x to 6.49.21. Those version mappings come from the thread, not from a matched official excerpt here.

If a device is still on an unpatched build and SSH, WWW/WWW-SSL, or bandwidth-test is reachable from untrusted networks, the risk described in the post is remote login or privilege abuse, not a browser download. Patching does not prove the device was never compromised earlier. The quoted advice itself says the absence of a flagged marker does not rule out prior compromise.

What to do next
1. Confirm the running RouterOS version and upgrade to a listed fixed build using your normal management path (WinBox, WebFig, or console), preferably from a trusted network.
2. After the upgrade, review logs for compromise-related messages and run /system/device-mode/print as described in the quoted recommendations. Check for unknown users, scripts, scheduled jobs, firewall rules, and unexpected tunnels or NAT.
3. Until the patch is applied, restrict SSH, WWW/WWW-SSL, and bandwidth-test to trusted management networks only. Avoid initiating TLS or using /system ssh and /system ssh-exec from an unpatched box toward untrusted hosts, as the post warns.
4. Compare findings against MikroTik’s security bulletin and Flagged documentation rather than relying only on forum quotes.

Do not run destructive cleanup scripts or assume the router is clean solely because an update succeeded.

Uncertainty
Whether any given router was already compromised before patching cannot be determined from this thread. Network exposure, which services were enabled, and whether SSH keys or admin accounts were reused are also unknown. If logs, unexpected accounts, or a flagged device-mode marker appear, treat that as a separate incident and follow MikroTik’s recovery guidance rather than guessing from the advisory text alone.

 

[Sorrento]

I really like my ASUS router, apart from its features the firmware is updated regularly & it checks itself for updates, a concern lately regarding some routers being exploited & users may never know.