MikroTrick Zero-Day Chain Gives Attackers Admin Control of MikroTik Routers

MikroTik RouterOS devices exposing SSH to the internet are under active attack through a vulnerability chain known as MikroTrick. The campaign can take an attacker from unauthenticated SSH access to full administrative control of a vulnerable router.

The chain combines CVE-2026-67276, a critical RSA-key authentication bypass rated CVSS 9.2, with CVE-2026-86060, an SSH-session privilege-escalation flaw. CERT Polska has confirmed successful compromises, including the creation of an unauthorized account named ops.

Security researcher Costin Raiu reported that exploitation may have begun on September 2, 2026, one day before MikroTik released relevant fixes. That sequence makes MikroTrick a zero-day campaign rather than exploitation that started only after public patch analysis.

Exploitation Preceded MikroTik’s Security Updates

Logs posted on a Polish security forum show apparent exploitation attempts dating to September 2. CERT Polska separately confirmed successful attacks beginning at least that day.

MikroTik released fixes in RouterOS 7.25beta3, 7.24.2, 7.23.4, and 6.49.21 on September 3, 2026. RouterOS 7.23.5, released on September 4, 2026, is also identified as patched.

Raiu published his technical analysis on September 5, 2026. On the same day, CERT Polska issued an advisory warning that critical RouterOS vulnerabilities were being actively exploited and urged customers to update immediately.

The timing suggests attackers may have known that fixes were imminent and started scanning or exploiting devices before administrators had patches available. Most observed activity originated from a single address, indicating an operation capable of targeting exposed routers at scale.

MikroTik also sent vulnerability warnings through its official mobile application. This was reportedly the first time the company had used that channel for a security alert.

No CISA Known Exploited Vulnerabilities catalog entry or associated federal remediation deadline has been disclosed for these flaws. However, confirmed exploitation already establishes that the risk is operational, not theoretical.

How the MikroTrick Chain Defeats SSH Authentication

CVE-2026-67276 concerns RouterOS validation of RSA public keys during SSH authentication. An attacker who knows a valid username and the public component of that user’s RSA key can construct a fraudulent key that RouterOS accepts without possession of the corresponding private key.

That breaks a fundamental SSH security assumption. Public keys are meant to identify authorized credentials, while the private key proves that the connecting party is their legitimate owner. Vulnerable RouterOS builds can be tricked into accepting authentication without that proof.

Unauthorized access is then combined with CVE-2026-86060, which enables privilege escalation within an SSH session. Chaining the two issues can give a remote, unauthenticated attacker full administrator control.

The attack path requires the RouterOS SSH service to be reachable from the attacker’s network. Routers exposing SSH directly to the public internet face the greatest danger, although a device could also be targeted from another untrusted or already-compromised network.

The two vulnerabilities are among six RouterOS flaws identified and coordinated for disclosure by CERT Polska. Exact vulnerable build ranges have not been disclosed. Administrators should therefore compare their installations against the fixed releases for the relevant branch rather than assume a slightly older build is safe.

The identified fixed versions are:

• RouterOS 7.25beta3
• RouterOS 7.24.2
• RouterOS 7.23.5
• RouterOS 7.23.4
• RouterOS 6.49.21

Both 7.23.4 and 7.23.5 have been presented as patched releases. Operators should install the current supported fixed release for their branch and verify the installed version after rebooting or completing the update process.

Administrative Access Exposes the Entire Network Perimeter

A compromised router gives attackers more than a foothold on one appliance. Administrator access can allow them to alter routing, weaken firewall policy, capture traffic, redirect connections, establish tunnels, or configure the device as a proxy.

Attackers may also add users and SSH keys, create scheduled tasks, deploy scripts, or change service settings to preserve access. Packet-sniffing features could expose traffic and credentials passing through the router, while manipulated routing or DNS-related configuration could send users toward attacker-controlled infrastructure.

Long-lived MikroTik installations are especially exposed when they receive limited maintenance. Routers can remain operational for years, making forgotten devices and unmanaged branch-office deployments likely candidates for delayed patching.

Devices using MikroTik’s default firewall configuration and not exposing SSH to the public internet are considered likely to be protected from this particular remote entry path. That does not establish that they are patched or uncompromised through other means. Their management exposure and software versions still require verification.

Logs and Configuration History Can Reveal Compromise

A failed MikroTrick attempt may create an authentication log entry containing the username -2. This is not a normal account name and should be investigated if it appears in RouterOS records.

Successful activity may be recorded under /system history in a form resembling:

ssh:-2@<IP>

Responders should correlate that event with subsequent administrative actions. Suspicious changes may include:

• Creation or modification of users and SSH keys
• New or altered scripts and scheduler entries
• Changes to enabled services
• Modified firewall or routing rules
• Proxy or tunnel activation
• Packet-sniffing configuration
• Other unexplained configuration changes

The unauthorized account ops is a confirmed campaign indicator. Its presence should trigger an immediate incident-response investigation.

Absence of a -2 entry does not prove that a router is clean. Logs may have rotated, been overwritten, or been erased by an attacker. A historical event showing ssh:-2@<IP> followed by a configuration action should be treated as confirmed compromise unless it came from an authorized security test.

Investigators should review current state as well as historical records. Users, keys, scripts, schedulers, services, firewall policy, proxies, tunnels, packet capture settings, and management access rules all require inspection.

Campaign Infrastructure and File Indicators

Most observed attacks came from 82.192.72[.]4, an address hosted by Leaseweb. A second address, 103.102.31[.]18, has also been associated with the campaign.

The primary address hosted four files:

• A MIPS build of the official precompiled BusyBox 1.16.1 binary, compiled in 2010
• ftpsrv.py
• launch.sh
• serve.py

Three supplied files had no VirusTotal detections at the time they were examined. Low or absent detection should not be interpreted as evidence that they are benign in this operational context.

Defenders can search collected files and telemetry using these SHA-256 hashes:

File	SHA-256
ftpsrv.py	6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d
launch.sh	972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd
serve.py	6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e

A hash for the BusyBox binary has not been disclosed. Historical network data should be searched for inbound or outbound connections involving both reported IP addresses.

Patch First, Then Investigate Exposed Routers

Administrators should update immediately to the appropriate fixed RouterOS release and confirm that the upgrade succeeded. SSH should be disabled or restricted wherever it is reachable from the internet or another untrusted network.

Management access should instead be limited to trusted administrative paths, tightly controlled source addresses, or protected internal access mechanisms. Filtering the two campaign addresses is useful, but it cannot replace patching because attackers can move to new infrastructure.

Any RouterOS device with internet-accessible SSH should be treated as potentially compromised until its logs, configuration history, users, keys, and active settings have been reviewed.

If unauthorized administrator activity is found, responders should isolate the router, preserve logs and configuration evidence, rotate passwords and SSH keys, remove persistence, and validate routing and firewall policy. Rebuilding or restoring the appliance through a trusted process may be necessary.

No functioning public proof of concept had been reported by September 5. Raiu estimated that one could appear on GitHub within one or two days, although active exploitation was already occurring without it. Waiting for public exploit code would therefore provide defenders no meaningful safety margin.