The active exploitation of MikroTik routers through internet-exposed SSH services demonstrates once again why edge devices deserve the same, and often greater, security attention as servers and endpoints. CERT Polska has warned that attackers are exploiting a two-vulnerability chain it calls MikroTrick to gain full administrative control of vulnerable MikroTik RouterOS devices without authentication when management services are reachable from the internet. Successful attacks have been observed since at least September 2, 2026, and MikroTik has released fixed RouterOS versions across affected branches. The precise two vulnerabilities forming the observed chain have not yet been publicly identified, and neither CERT Polska nor MikroTik has disclosed enough technical detail to independently reconstruct exactly how the chain bypasses authentication. Even so, the operational impact is clear: an unauthenticated remote attacker can potentially take control of a router that exposes affected management services. 

The affected RouterOS ranges are broad. CERT Polska identifies RouterOS 6.0.0 through versions earlier than 6.49.21, RouterOS 7.0.0 through versions earlier than 7.23.4, and RouterOS 7.24 through versions earlier than 7.24.2 as vulnerable. MikroTik released 6.49.21, 7.23.4 and 7.24.2 as initial security fixes, while 7.25beta3 contains the fix in the development channel. Because 7.23.4 introduced an IPv6 DHCP regression, MikroTik subsequently released 7.23.5, which retains the security correction while fixing that separate issue. Administrators should therefore use current vendor-supported releases rather than mechanically upgrading only to the first build carrying the security patch.

The absence of authentication is what makes the situation particularly dangerous. Many router compromises begin with weak passwords, exposed WinBox interfaces, credential reuse or outdated administrative accounts. In this case, the attacker may not need valid credentials at all. If the vulnerable SSH service is reachable, exploitation can potentially occur before the normal authentication boundary becomes relevant. This changes the defensive priority considerably because password rotation or stronger authentication does not address the underlying exposure. The vulnerable software has to be updated, and unnecessary management access has to be removed from the internet.

The problem also illustrates why management-plane exposure is so dangerous on network infrastructure. Routers exist at a highly trusted position in the environment. They decide where traffic goes, which networks can communicate and frequently provide firewalling, NAT, VPN, DNS and administrative services. An attacker who gains full administrative control does not merely obtain access to another Linux-like appliance. They gain control over one of the systems that defines the network itself. Depending on configuration and attacker objectives, that could allow modification of routes, firewall rules, DNS settings, VPN configuration, port forwarding, user accounts, scripts and other behaviour that affects every system behind the device.

This is why router compromise can be much more strategically useful than compromising a single workstation. An infected laptop gives the attacker one endpoint. A compromised router may provide visibility or influence over traffic belonging to many endpoints simultaneously. It can also become a persistent foothold that survives endpoint remediation because the security team may clean infected computers while overlooking the device that continues to redirect, proxy or manipulate their traffic.

MikroTik devices have already demonstrated their usefulness to sophisticated attackers. Earlier in 2026, Russia-linked APT28 was associated with a large-scale campaign compromising MikroTik and TP-Link routers and modifying DNS settings to intercept authentication traffic. In that operation, compromised routers were used as infrastructure for DNS hijacking and attacker-in-the-middle activity targeting sensitive organizations. That campaign is separate from the current MikroTrick activity, but it illustrates why threat actors repeatedly target SOHO and edge routers: once compromised, these devices can provide both operational access and infrastructure that blends naturally into ordinary internet traffic.

One of the most useful aspects of CERT Polska’s warning is that it goes beyond patching and explicitly tells administrators to inspect routers for evidence of compromise. RouterOS can mark devices as Flagged when startup checks detect suspicious configuration. In that condition, certain entries are disabled and some functionality is restricted. Administrators are advised to check the device status using `/system/device-mode/print` and review logs and configuration for unknown users, scripts and other unexpected changes. CERT also identifies suspicious highly privileged `ops` accounts and account-creation log entries containing `ssh:-2@` as indicators requiring investigation.

That distinction is essential because patching a compromised router is not the same as restoring trust in it. If an attacker obtained administrative control before the update was installed, they may already have created new users, changed scripts, modified firewall rules, altered DNS, added scheduled tasks or established another persistence mechanism. Installing the fixed RouterOS release closes the vulnerability but does not automatically remove those changes. Security teams should therefore determine whether the router was vulnerable and internet-accessible during the exploitation window and, if so, perform compromise assessment rather than treating the firmware update as the entire response.

CERT Polska’s recovery guidance is appropriately cautious. If logs, configuration or Flagged status suggest compromise, administrators should isolate the router and preserve logs and configuration before making destructive changes. They should then restore factory settings and rebuild the system from a trusted, verified configuration rather than blindly restoring a complete backup from the potentially compromised router. Passwords, SSH keys and other secrets associated with the device should also be changed.

The advice not to restore a potentially compromised backup is particularly important. Router backups are often treated as trusted recovery material, but if the attacker has already modified users, scripts, firewall rules or other persistent configuration, restoring that backup may simply reinstall the attacker’s changes on a freshly reset device. A known-good baseline created before compromise is considerably safer than an export taken after suspicious activity began.

Organizations should also review the router’s DNS configuration. A compromised router does not need to remain visibly malicious to have significant impact. Changing the DNS servers handed out to internal clients can redirect authentication traffic toward attacker-controlled infrastructure while most browsing continues to function normally. Similarly, subtle routing or NAT modifications can selectively redirect only certain destinations. Defenders should therefore compare DNS, routing, firewall and NAT settings against known-good configuration rather than looking only for obviously malicious accounts.

Temporary mitigations are available for systems that cannot be updated immediately. CERT recommends disabling exposed services or restricting them to trusted management networks, with particular attention to SSH, WWW/WWW-SSL and the bandwidth-test service. It also advises administrators not to initiate TLS connections or use RouterOS’s built-in SSH clients from an unpatched device. These restrictions address the broader set of reported vulnerabilities but do not replace the vendor updates.

The management-access recommendation deserves emphasis because it remains useful even after patching. Router SSH, web administration and similar services should generally not be exposed directly to the public internet unless there is an exceptional operational requirement. Administrators should instead use dedicated management networks, VPN connectivity, restrictive source allowlists or other controlled access paths. MikroTik itself notes that its default firewall rules for home devices block public access to management ports while those defaults remain intact. The risk frequently appears when users modify or remove those protections.

This creates an important configuration-management lesson. Vendor defaults often provide a reasonable baseline, but administrators can unknowingly defeat those protections over time while troubleshooting remote access or adding services. A temporary firewall exception can become permanent, an SSH service can remain exposed after a project ends, or a router can be installed using an old configuration copied from another device. Periodic external exposure scanning can identify management ports that have become reachable unintentionally.

The fact that no victim count or attacker identity has yet been published should also not be misread as evidence that exploitation is limited. CERT Polska has confirmed attacks, but attribution and scale remain unknown. That is common during the early stages of an active exploitation campaign. Attack infrastructure may be distributed, attackers may rotate addresses quickly and compromised devices themselves can be used to launch subsequent activity. Waiting for a named threat group or a large victim number before patching simply gives the campaign more time to mature.

The zero-day question also remains unresolved. The attacks were observed beginning September 2, while security fixes were announced around September 3. However, the available public timelines do not establish whether patched builds were already available before the first observed exploitation. The Hacker News therefore correctly notes that describing MikroTrick as confirmed zero-day exploitation would currently go beyond the available evidence.

For defenders, that uncertainty changes very little operationally. Organizations should identify MikroTik routers, determine their RouterOS versions, check whether SSH or other management services are reachable from untrusted networks and upgrade immediately to the appropriate fixed release. Systems that were vulnerable and exposed should receive additional forensic attention, particularly if unexplained accounts, scripts, configuration changes or Flagged status are present.

Network teams should also monitor inbound connections to router-management ports and maintain centralized logging outside the router itself. If an attacker gains administrative access, logs stored exclusively on the compromised device may no longer be reliable. Sending RouterOS logs to an independent syslog or SIEM platform gives defenders a historical record that is harder for an attacker on the router to modify.

Configuration integrity should receive similar treatment. Organizations operating large numbers of MikroTik routers should maintain known-good configuration snapshots and automatically detect changes to critical settings such as DNS servers, firewall policies, NAT rules, VPN configuration, administrative accounts and scripts. A router’s configuration should be treated like executable security policy because changing those settings can materially alter how the entire network behaves.

The broader lesson from MikroTrick is that edge devices cannot remain outside mainstream vulnerability-management programmes. Routers are often deployed and then left operating for years because they appear stable and require little day-to-day attention. That operational stability is useful, but it can also allow outdated firmware and accidental internet exposure to persist unnoticed.

Attackers understand this very well.

A router that has been quietly forwarding traffic for five years may look boring to the administrator.

To an attacker, it may be an internet-facing privileged computer that controls an entire network and receives considerably less monitoring than any workstation behind it.

MikroTrick is another reminder that the network edge is not merely where attacks arrive.

Increasingly, it is one of the places attackers want to own.

Attackers are exploiting MikroTik routers with their Secure Shell (SSH) remote-access service, which is reachable from the internet, to gain full administrative control without authentication, according to CERT Polska's attack warning, published on September 5. Successful attacks date to at least September 2. The Hacker News’s September 6 review of the warning found no victim count or

Source: Attackers Hijack MikroTik Routers Through Internet-Exposed SSH Without Authentication via The Hacker News — published 06 Sep 2026.