Threat actors are actively exploiting critical vulnerabilities in MikroTik RouterOS, collectively known as MikroTrick, to compromise internet-exposed routers and gain complete administrative control.
The attacks primarily target devices with SSH management access exposed to public networks, prompting urgent patching guidance from MikroTik, CERT Polska, and Latvia’s CERT.LV.
MikroTik released security updates on September 3, confirming that fixed RouterOS builds are available through supported update channels. Although the company said most default configurations are not immediately exposed, it urged every administrator to update vulnerable devices without delay.
Hackers Actively Exploit MikroTik RouterOS MikroTrick Flaws
The affected components include the RouterOS SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig web management interface.
Researchers identified six RouterOS vulnerabilities, including two critical SSH flaws that attackers can chain to obtain unauthenticated, full-device access.
The first issue, CVE-2026-67276, carries a CVSS score of 9.2 and stems from an SSH authentication-bypass vulnerability. RouterOS reportedly fails to fully compare the contents of RSA public keys during authentication.
An attacker who knows a valid username and the public modulus associated with that account’s SSH key can generate a different key that passes validation. This enables the attacker to log in without the legitimate private key and inherit the permissions assigned to the targeted user.
The second critical vulnerability, CVE-2026-86060, also has a CVSS score of 9.2. It affects RouterOS’s processing of specially crafted SSH usernames that begin with a prohibited character. Exploiting the improper username handling can allow attackers to manipulate session privileges and obtain administrator-level access.
CERT.LV has reported increased activity targeting publicly accessible RouterOS devices in Latvia. In observed incidents, attackers successfully combined the two SSH flaws to seize control of vulnerable routers.
A third issue, CVE-2026-67277, has a CVSS score of 8.8 and affects the RouterOS bandwidth-test service. The vulnerability may allow an unauthenticated connection to enter a state that should be available only after successful authentication.
When combined with separate flaws involving exposure of uninitialized packet-buffer data and integer underflow during size validation, the issue could expose kernel memory or cause a remote denial-of-service condition that restarts the router.
These bugs may not independently result in administrative takeover, but they substantially expand the risk for unpatched systems.
MikroTik released fixes in RouterOS versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. Updated devices will automatically inspect their configurations for known indicators of compromise during startup.
Patched devices can be assigned a “Flagged” status when suspicious configuration modifications are detected. RouterOS disables identified malicious entries, logs a critical event, and activates the warning state.
However, MikroTik and CERT.LV caution that an unflagged device should not be considered definitively clean.
Known indicators include the log messages login failure for user -2 from via ssh and user added by ssh:-2@, along with the presence of a highly privileged account named ops.
CERT Polska linked exploitation involving the ops account to IP address 82.192.72.4, while another address, 103.102.31.18, has been observed attempting the exploit chain.
Administrators should immediately patch RouterOS and inspect affected systems for unauthorized users, scripts, scheduled tasks, proxies, tunnels, and other unexpected configuration changes. The device state can be checked using /system/device-mode/print.
Organizations unable to patch immediately should restrict SSH, WWW/WWW-SSL, and bandwidth-test services to trusted administrative networks.
If compromise is suspected, administrators should isolate the router, preserve logs and configuration evidence, create a Supout.rif diagnostic file, reset the device to factory defaults, and rebuild it from a known-good configuration.
All passwords, SSH keys, and secrets should be rotated, and potentially compromised full-device backups should not be restored.
Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN
