MikroTik Releases Critical RouterOS Security Updates

Six CVEs, active exploitation, multiple RouterOS release chains, and what MikroTik administrators need to know

MikroTik released another RouterOS update. Yeah, that's not exactly uncommon.

What is uncommon is releasing security updates across multiple RouterOS release chains at essentially the same time.

MikroTik released patched versions for the Stable, Long-Term, Development, and even legacy RouterOS v6 release chains. The fixes are included in RouterOS 7.24.2, 7.23.4, 7.25beta3, and 6.49.21.

RouterOS 7.23.5 was subsequently released for the Long-Term channel to correct an urgent IPv6 DHCP issue introduced in 7.23.4. So, if you're upgrading a Long-Term router today, 7.23.5 is the version we would recommend rather than stopping at 7.23.4.

Why all the urgency?

There isn't just one vulnerability involved here. There are six published CVEs, including two with CVSS scores of 9.2. Even more importantly, researchers have now confirmed that a combination of the SSH vulnerabilities is actively being exploited against MikroTik routers accessible from the public Internet.

So, What Versions Are Vulnerable?

The exact vulnerable version range varies between the six CVEs, so saying that every CVE affects every RouterOS release below one specific version isn't technically correct.

What matters operationally is that MikroTik released fixes in:

• RouterOS v6: 6.49.21
• RouterOS v7 Long-Term: Fix introduced in 7.23.4; 7.23.5 is now available and also fixes an IPv6 DHCP regression introduced in 7.23.4
• RouterOS v7 Stable: 7.24.2
• RouterOS v7 Development: 7.25beta3

Some of the individual vulnerabilities affect RouterOS v6, while others only affect particular RouterOS v7 releases. Unless you have a specific operational reason to analyze each CVE against every router individually, the practical recommendation is much simpler: upgrade to a current patched release.

I honestly don't expect many operators to still be running RouterOS v6 at this point, but there are certainly legacy systems out there. MikroTik did patch 6.49.21; however, MikroTik has also made it clear that v6 is no longer actively developed and recommends moving to RouterOS v7.

Your Management Plane Should NOT Be Public

This incident is also a really good example of why we have recommended for years that your router's management plane should not be exposed directly to the public Internet.

The six disclosed vulnerabilities affect several different RouterOS components, including:

• SSH server authentication and session handling
• RouterOS SSH client functionality
• The RouterOS bandwidth-test service
• X.509 certificate validation used for outbound TLS connections
• WebFig

One important correction from some of the early information circulating about this issue: FTP itself is not one of the six vulnerabilities disclosed by CERT Polska.

The most serious currently observed attack involves SSH.

CERT Polska has named the attack chain MikroTrick. By combining two of the SSH vulnerabilities, an attacker can potentially obtain full administrative control of a RouterOS device when SSH is accessible from an untrusted network.

That is also why simply changing the SSH port isn't a security solution. Management services should be protected by firewall rules and restricted to trusted management networks, known administrative addresses, or accessed through a VPN.

MikroTik specifically recommends that WinBox, WebFig, and SSH not be exposed directly to the Internet and recommends using a firewall and a strong VPN such as WireGuard for remote administration.

What Are the Six Vulnerabilities?

Now that the technical details have been published, we have a much better picture of what was actually fixed.

CVE-2026-67276 – SSH Authentication Bypass – CVSS 9.2

RouterOS did not completely validate an RSA public key during SSH authentication. Under the right conditions, an attacker who knows information about an authorized RSA key could construct a different key and authenticate as that RouterOS user without possessing the user's private key.

This vulnerability affects RouterOS v7 releases beginning with 7.9 and does not have the same affected-version range as the other SSH vulnerabilities.

CVE-2026-86060 – SSH Privilege Escalation – CVSS 9.2

A flaw in how RouterOS handles specially crafted usernames during SSH login can alter the RouterOS privilege policy associated with the session. An unauthenticated SSH connection that reaches the affected login process can ultimately obtain elevated privileges.

This is particularly serious because it can be combined with other SSH weaknesses. The combination being actively exploited has been named MikroTrick.

CVE-2026-67277 – Bandwidth-Test Authentication Bypass / Memory Disclosure / DoS – CVSS 8.8

The RouterOS bandwidth-test service can accept a related connection before the primary session has actually completed authentication. This can allow an unauthenticated attacker to reach functionality that should only be available after login.

The vulnerability can disclose portions of kernel memory and can also trigger a condition that causes the RouterOS kernel to restart, resulting in a remote denial-of-service condition.

CVE-2026-67278 – X.509 Certificate Validation – CVSS 6.3

This one is different because it isn't primarily about someone connecting to a management service on your router.

A flaw in RouterOS RSA/PKCS#1 v1.5 signature validation can allow forged certificates to be accepted under specific conditions. An attacker capable of intercepting or redirecting an outbound TLS connection from an affected RouterOS device could potentially impersonate a TLS server.

This is one reason that simply blocking inbound management access does not completely eliminate the need to upgrade.

CVE-2026-67279 – Unauthenticated SSH Session / File Access – CVSS 6.9

A flaw in the RouterOS SSH connection state machine can allow a client to reach the SSH connection protocol without completing normal user authentication.

An unauthenticated attacker can potentially execute functionality that allows files within the RouterOS managed file namespace to be created, overwritten, or reconstructed, including files containing configuration or diagnostic information.

CVE-2026-67281 – WebFig Unauthenticated File Read – CVSS 8.7

WebFig contains an unauthenticated file-read vulnerability involving its /jsproxy functionality and an uninitialized authorization pointer.

Under the right conditions, an unauthenticated attacker can potentially escape the normal WebFig file namespace and read files owned by the RouterOS system, including configuration data that may contain credentials.

Yes, These Vulnerabilities Are Being Exploited

This is probably the most important update since the original MikroTik security announcement.

CERT Polska has confirmed attacks against RouterOS devices accessible from the Internet. The researchers confirmed that attackers are combining vulnerabilities to obtain full control of routers with SSH exposed to public networks.

So this isn't just a theoretical CVE anymore.

If you have an Internet-facing MikroTik with SSH exposed, don't simply upgrade it and assume you're done. You should also investigate whether the router may already have been compromised.

After You Upgrade – Check the Router

The patched RouterOS releases include functionality that checks for known indications of compromise during startup.

If RouterOS detects certain suspicious configuration changes, the device can be placed into a Flagged state and a critical message will appear in the log.

You can also check the device mode from the RouterOS command line:

/system/device-mode/print

However, this is important: a router that is not Flagged is not automatically clean.

The Flagged mechanism looks for known indicators. The absence of those indicators does not prove that a router was never compromised.

After upgrading, review the router for:

• Unknown users
• Unknown scripts
• Unexpected scheduler entries
• Unknown proxy configuration
• Unexpected tunnels or VPN interfaces
• Unexpected firewall or NAT rules
• Other configuration changes you don't recognize

If you find evidence that the router was compromised, don't just delete the suspicious user and put the router back into production. Preserve the logs and configuration for investigation, isolate the device, reset it, rebuild it from a known-good configuration, and rotate passwords, SSH keys, VPN credentials, API credentials, and other secrets that may have been accessible from the router.

Do not blindly restore a full binary backup taken from a potentially compromised router.

MikroTik's Response Has Been Excellent

Vulnerabilities happen. What really matters is how a vendor responds when they are discovered.

In this case, I think MikroTik deserves a lot of credit.

They produced patched releases across the Stable, Long-Term, Development, and even legacy v6 release chains. They notified customers, published security information, communicated through their forums and community channels, and even sent push notifications to users with the MikroTik mobile application installed.

They also added the Flagged detection and mitigation functionality to help identify systems showing known signs of compromise.

And once an urgent IPv6 DHCP problem was identified in 7.23.4, MikroTik followed it with 7.23.5 to correct that issue as well.

That's a pretty aggressive response to a serious security problem.

I don't think MikroTik could have done much more here.

What Should You Do Right Now?

1. Upgrade RouterOS to a current patched release.
2. Immediately remove public access to SSH, WebFig, WinBox, bandwidth-test, and other unnecessary management services.
3. Restrict management access using firewall rules and dedicated management networks.
4. Use a VPN such as WireGuard for remote management.
5. After upgrading, check Flagged status and review the RouterOS logs.
6. Inspect users, scripts, scheduler entries, tunnels, proxies, firewall rules, and other configuration for anything you don't recognize.
7. If compromise is suspected, isolate and rebuild the router from a trusted configuration and rotate credentials.

Need Help Upgrading Your MikroTik Network?

Updating one MikroTik is easy. Updating dozens, hundreds, or thousands of routers in a production ISP or enterprise network is a different story.

Before doing a large-scale RouterOS upgrade, you need to consider hardware architectures, installed packages, current RouterOS versions, configuration compatibility, available storage, maintenance windows, remote accessibility, configuration backups, and what happens if a router doesn't come back after rebooting.

Link Technologies, Inc. can help.

Our MikroTik engineers can assist with planning and performing RouterOS upgrades, reviewing your management-plane security, checking Internet-facing devices, and helping determine whether suspicious configuration changes may indicate a compromised router.

For networks with larger numbers of MikroTik devices, centralized management can make this process considerably easier.

Admiral – Centralized MikroTik Management

Admiral provides centralized management and automation for MikroTik networks, including remote access, backups, firmware management, bulk configuration, monitoring, and other tools designed specifically for RouterOS environments.

For an event like this, having your MikroTik devices centrally inventoried and managed makes it much easier to determine what RouterOS versions are deployed across the network, create backups, coordinate firmware upgrades, and manage large numbers of routers without logging into every device individually.

If you're managing dozens or hundreds of MikroTik routers manually, this is also a good time to look at how you're managing the network long term.

Learn More About Admiral

LTI Cloud Services

If you need hands-on assistance rather than doing the upgrade yourself, LTI Cloud provides access to Link Technologies' support and managed-service infrastructure.

Our engineers can work with you to review your RouterOS environment, develop an upgrade plan, perform upgrades in a controlled manner, review management access, and troubleshoot devices that have problems during or after the upgrade.

This is especially useful for ISPs and organizations where taking hundreds of routers offline at the same time simply isn't an option. Upgrades can be planned and staged around network topology, customer impact, maintenance windows, and available redundancy.

LTI Cloud Services

Final Thoughts

No vendor is going to have a perfect security record. That's simply not realistic.

What we should expect is for vendors to respond quickly when vulnerabilities are discovered, provide patches, communicate clearly with their customers, and give network operators the information they need to protect their systems.

From what we've seen with this issue, MikroTik did exactly that.

For MikroTik administrators, the action items are straightforward: protect your management plane, get your routers patched, and check them for evidence of compromise.

And if you're managing enough MikroTik devices that doing that manually is a major project, Link Technologies can help you get it done.

References

• MikroTik – September 2026 Vulnerability
• MikroTik Forum – Important Security Update
• MikroTik RouterOS Documentation – Flagged Status
• CERT Polska – Critical RouterOS Vulnerabilities Actively Exploited
• CERT Polska – MikroTik RouterOS CVE Details
• Reversing MikroTik's Silent Patch: The RouterOS 7.23.4 Fix They Wouldn't Explain

About Link Technologies, Inc.

Link Technologies, Inc. provides network engineering, consulting, training, managed services, and support for ISPs, WISPs, enterprise networks, and organizations using MikroTik RouterOS.