MikroTik Attacks Reach Latvia: 12 Devices Compromised and Thousands Potentially Exposed

Latvia has already identified 12 compromised MikroTik devices, while several thousand devices are exposed to the internet. CERT.LV warns that attackers are actively combining two RouterOS vulnerabilities to take over devices whose SSH management service is accessible from public networks.

Businesses should act immediately: update RouterOS, restrict access to management services and investigate whether an attacker has already added users, scripts, scheduled tasks, proxy servers or tunnels.

What has been confirmed in Latvia?

In its 7 September 2026 update, CERT.LV reported 12 identified MikroTik device compromises in Latvia. It also identified several thousand internet-exposed devices and is notifying their operators.

On 3 September, CERT.LV warned Latvia’s critical-infrastructure operators and requested immediate updates. It also contacted other operators whose equipment was considered to be at high risk.

The figure of several thousand does not mean that every device has been compromised. It refers to internet-exposed equipment that may be at risk depending on its RouterOS version and configuration.

What is the MikroTrick vulnerability chain?

CERT Polska identified six vulnerabilities affecting the RouterOS SSH server and client, bandwidth-test service, X.509 certificate handling and WebFig management interface.

The most dangerous combination, named MikroTrick, links two SSH vulnerabilities:

CVE-2026-67276 — an SSH public-key authentication bypass rated CVSS 9.2;
CVE-2026-86060 — SSH session privilege manipulation resulting in full administrative privileges, also rated CVSS 9.2.

When combined, the vulnerabilities have enabled the observed attackers to obtain full RouterOS administrative control without valid authentication credentials.

Is every MikroTik device exposed to complete takeover?

No. The full-takeover scenario confirmed by CERT Polska and CERT.LV concerns devices running vulnerable RouterOS versions whose SSH management service is accessible from a public or otherwise untrusted network.

MikroTik’s default configuration blocks SSH access from the internet. The risk increases when an administrator has manually opened access, created an excessively broad firewall rule or unintentionally exposed the service through misconfiguration.

Checking SSH alone is nevertheless insufficient. Other disclosed vulnerabilities also affect bandwidth-test, X.509 certificate handling, the built-in RouterOS SSH client and WebFig.

Which RouterOS versions should be installed?

CERT.LV’s 7 September update lists the latest published versions as:

7.24.2 in the stable channel;
7.23.5 in the long-term channel;
6.49.21 in the RouterOS 6 long-term branch;
7.25beta3 in the beta channel.

MikroTik’s original security bulletin states that fixes were already included in versions 7.24.2, 7.23.4, 6.49.21 and 7.25beta3. As version 7.23.5 was subsequently released, administrators should install the latest version offered in the appropriate channel for their device.

A production device should not be moved to the beta channel merely because its version number is higher. Keep the organisation’s selected stable or long-term channel and update it to the latest available release.

How should a business check its MikroTik device?

Determine who manages the device. If it is provider-managed, obtain confirmation that the update has been installed.
Check the RouterOS version. Immediately update self-managed equipment to the latest fixed version in the selected channel.
Review management exposure. SSH, WWW, WWW-SSL, WinBox and other administration services must not be freely accessible from the internet.
Check the “Flagged” status. After updating, review both the system log and the device’s “Flagged” marker.
Review users and configuration. Look for unknown accounts, scripts, scheduler tasks, proxy servers, tunnels, interfaces and firewall changes.
Investigate connected systems. If the router was compromised, assess whether the attacker could have reached internal servers, cameras, workstations or cloud credentials.

What may indicate a compromise?

CERT.LV and CERT Polska list several indicators observed during attacks:

a critical log entry and active “Flagged” status;
SSH login failures involving a user named “-2”;
log entries showing a user added through an SSH session involving “-2”;
an unknown privileged account named “ops”;
unrecognised scripts, scheduled tasks, proxy servers or tunnels;
unexplained DNS, routing, firewall or remote-access changes.

The absence of these indicators does not prove that the device is clean. The “Flagged” mechanism detects only selected known changes, and an attacker may attempt to remove evidence.

What should be done if compromise is suspected?

Isolate the device from the internet and the internal network.
Before resetting it, preserve logs, configuration data and the Supout.rif diagnostic file.
Report the incident to CERT.LV and provide the preserved material for analysis.
After preserving evidence, reset the device to factory settings.
Install a fixed RouterOS version and rebuild the device from a trusted configuration.
Do not blindly restore a complete backup taken from a potentially compromised device.
Replace passwords, SSH keys, API credentials, VPN secrets and other credentials stored on the device.
Investigate internal systems that were accessible through the router or whose traffic it handled.

Do not clear the “Flagged” marker before the investigation is complete and the necessary evidence has been preserved.

What if the update cannot be installed immediately?

Until the update is installed, CERT.LV recommends disabling publicly accessible management services or limiting them by firewall rules to trusted administrative addresses. SSH, WWW, WWW-SSL and the bandwidth-test server require particular attention.

Using a VPN such as WireGuard is safer than exposing management ports directly to the internet. The built-in RouterOS SSH client should not be used from an unpatched device to connect to untrusted hosts.

These are temporary risk-reduction measures. They do not replace updating RouterOS and inspecting the device.

Frequently asked questions

Should an ordinary home MikroTik router be disconnected immediately?

Not necessarily. MikroTik’s default configuration blocks SSH from the internet, but the vendor still recommends updating all devices. If the router is managed by a service provider, ask the provider to confirm its update status.

Is updating RouterOS sufficient?

No. An update fixes the known vulnerabilities but does not reverse configuration changes already made by an attacker. Users, scripts, scheduler tasks, proxy servers, tunnels and logs must also be checked.

Does “Flagged=no” mean the router is secure?

No. The absence of the marker does not exclude an earlier compromise because the mechanism detects only selected known traces.

Is changing the administrator password sufficient?

No. The observed vulnerability chain can bypass authentication and obtain administrative privileges. RouterOS must be updated, public management access closed and the entire configuration reviewed.

Can the router backup be restored after a reset?

A complete backup from a potentially compromised device should not be restored blindly because it may contain attacker-created changes. Rebuild the device from a trusted, verified configuration.

Information updated on 8 September 2026. Security recommendations and available RouterOS versions may be updated further.