Blog

Update Your MikroTik Before Someone Else Does

MikroTrick vulnerabilities are being exploited against MikroTik devices with exposed SSH. RouterOS updates are available and should be installed now.

Dmytro
mikrotik routeros security-update network-security

Update Your MikroTik Before Someone Else Does

MikroTik equipment is everywhere. It routes traffic in homes and offices, connects racks in datacenters, and runs virtually as Cloud Hosted Router, or CHR. A small RouterOS virtual machine can quietly handle routing, VPNs, and firewall duties for years. This is convenient right up to the moment everyone forgets that it still runs software and needs updates.

This week brought a particularly firm reminder. As reported by The Hacker News, attackers are taking control of internet-accessible MikroTik devices through vulnerabilities in RouterOS. This is not a theoretical laboratory result. CERT Polska has confirmed active exploitation on devices with SSH exposed to public networks.

If you operate RouterOS on hardware or in a CHR virtual machine, it needs attention now.

What is MikroTrick?

CERT Polska found six RouterOS vulnerabilities affecting the SSH server and client, bandwidth-test service, certificate validation, and WebFig. The most urgent attack chain, named MikroTrick, combines SSH flaws to obtain full control of a device without normal authentication.

The disclosed issues include an SSH public-key verification flaw, CVE-2026-67276, and privilege manipulation through a crafted username, CVE-2026-86060. Other vulnerabilities allow unauthorized file operations, disclosure of kernel memory, a remote restart through the bandwidth-test service, forged certificate acceptance in some outbound TLS connections, and reading files through WebFig. CERT Polska provides the complete CVE and affected-version list.

The practical takeaway is simpler than the CVE list: the patched releases stop the attacks observed by CERT Polska. An exposed, unpatched management service provides attackers with a much more interesting weekend than it provides you.

Which RouterOS versions contain the fix?

MikroTik’s September 2026 security bulletin lists fixes in:

  • 7.24.2 for the stable channel;
  • 7.23.4 for the long-term channel;
  • 6.49.21 for RouterOS 6;
  • 7.25beta3 for the beta channel.

Upgrade to the current patched release for your channel. You can use System > Packages > Check for Updates in WinBox or WebFig. Before updating, export the configuration and keep the copy somewhere other than the router. Also confirm that the device has enough free storage and reliable power. For CHR on a VDS, make sure you can open the VNC console from the service control panel in case networking does not return as expected.

Do not postpone the update because SSH uses keys or a strong password. This incident includes failures in authentication handling itself. A very strong lock is less impressive when the flaw is in the doorframe.

Check the device after updating

The fixed RouterOS releases inspect the configuration during startup for known signs of unauthorized changes. If suspicious entries are found, RouterOS writes a critical log message and sets the device to Flagged status. Check the logs and run:

/system/device-mode/print

CERT Polska observed SSH log entries involving the user -2 and the creation of a highly privileged account named ops. Administrators should also look for unknown users, scripts, scheduler tasks, proxy services, tunnels, firewall rules, or other settings they did not create.

The absence of flagged: yes is good news, but it is not proof that the device was never compromised. The detector recognizes selected traces, not every possible change.

If the device is flagged or contains unexplained modifications, isolate it. Preserve its logs and configuration before resetting anything, then follow the official RouterOS Flagged-status guidance. CERT Polska recommends restoring factory settings, rebuilding from a trusted and verified configuration, and changing passwords, keys, and other secrets. Do not blindly restore a full backup taken from a device that may already have been compromised. Backups are excellent at preserving whatever you give them, including mistakes and malicious configuration.

If updating is temporarily impossible, disable SSH, WWW, WWW-SSL, and the bandwidth-test server or restrict them to trusted networks. This only reduces exposure until the update can be installed. It is not a substitute for patching.

Updates are maintenance, not an optional feature

Routers often remain untouched because they are stable. Unfortunately, “it has routed packets since 2021” is an uptime observation, not a security policy.

RouterOS is software, whether it runs on a small plastic box, a carrier router, or a CHR instance in a datacenter. Each device needs an owner, a supported release channel, regular update checks, and a maintenance window. Keep an inventory so that virtual routers are not forgotten after the project that created them has changed names three times. Management services should not be exposed to the entire internet. MikroTik’s own router security guide recommends keeping RouterOS current, disabling unused services, restricting management access, monitoring logs, and using a VPN for remote administration.

Updates are not an optional improvement to install when the interface looks old. They are part of operating the device.

Keep configuration somewhere safer than the router

RouterOS supports both binary backups and human-readable configuration exports. MikroTik recommends creating backups after important configuration stages and warns that binary backups contain sensitive data. A binary backup is intended for restoration on the same device and RouterOS version. A text export is easier to review and useful for rebuilding a configuration, but some secrets, certificates, and keys require separate handling. The RouterOS configuration-management documentation explains the differences.

Whichever format you use, copy it off the device. A backup stored only in the router’s own file list is unlikely to impress anyone after the router is lost, reset, or compromised.

For automatic, versioned configuration copies, two useful options can run on a separate VDS:

  • Oxidized is an open-source network configuration backup tool with a RouterOS model. It can retrieve configurations over SSH using a dedicated read-only account and keep revisions in Git. Its RouterOS notes include current SSH-key setup instructions.
  • Unimus is an on-premises network configuration management platform with scheduled backups, history, diffs, and automation. Its supported-device list includes MikroTik RouterOS on RB, CCR, CRS, x86, and CHR systems.

Place the backup service outside the failure domain it protects. If RouterOS runs as CHR on one VDS, storing its only backup on that same VDS is file organization, not disaster recovery. Another VDS, location, or independently protected storage target is a better home. Encrypt sensitive backups and test that you can actually restore or rebuild from them.

Watch the quiet boxes

Finally, monitor the devices. Send RouterOS logs to a remote syslog service, alert on new users and configuration changes, and watch availability, resource use, interface state, and unexpected traffic. A monitoring system such as LibreNMS can run on a modest VDS and integrate with Oxidized for configuration history. The exact tool matters less than noticing that a router changed before somebody reports that the network has developed a personality.

MikroTrick deserves immediate action, but the lesson is not limited to this incident. Update RouterOS, inspect every physical and virtual MikroTik device, restrict management access, keep verified configuration copies away from the device, and monitor what changes.

Network equipment is infrastructure, not furniture. It should not be left in a corner until it starts communicating with strangers.

Need Help?

Our support team is available 24/7 to assist you with any questions or issues.

Contact Support