Secretus logo
newsmikrotikrouterosmikrotrick

MikroTrick Is Actively Exploited: Patch MikroTik and Rotate Secrets After Router Takeover

CERT Polska confirmed active MikroTrick exploitation against exposed RouterOS SSH services. Patch, investigate, rebuild trust and rotate reachable secrets.

·8 min read·Secretus Editorial

CERT Polska has confirmed active exploitation of a two-vulnerability chain it calls MikroTrick against MikroTik RouterOS devices with SSH reachable from public networks. The chain can bypass SSH authentication and produce a session with full administrative privileges. MikroTik has released fixed RouterOS versions and recommends upgrading even though it says most configurations are not immediately at risk.

This is not a patch-only event. A router that may have been administered by an attacker can expose or alter the trust paths around VPNs, monitoring, automation and recovery. Teams should contain and investigate first, rebuild a trustworthy configuration, and then replace the passwords, keys and other secrets that the device could reach.

What CERT Polska and MikroTik confirmed

CERT Polska identified six RouterOS vulnerabilities and coordinated disclosure with MikroTik. The two most serious issues, CVE-2026-67276 and CVE-2026-86060, are each rated CVSS 9.2 by the researchers. Combined, they allow an attacker to obtain full control of an affected device without possessing the expected SSH private key.

CERT Polska says it observed successful attacks from at least September 2, 2026. The activity included creation of a highly privileged account named ops on some devices. That artifact is an indicator to investigate, not a complete test: the researchers explicitly warn that an absence of known traces does not prove a device was never compromised.

Fixes are available in RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21. MikroTik says the updated software can mark a device as Flagged when it recognizes selected unauthorized changes. The marker is useful evidence, but it detects only known patterns and should not replace a broader review of logs and configuration.

Patch before rotating credentials

Changing an administrative password while the vulnerable service remains exposed can hand the replacement straight back to an attacker. The same problem exists when a team rotates a VPN key but leaves an unknown administrator, script, scheduler task, tunnel or proxy configuration on the router.

  1. Update immediately. Move to a fixed RouterOS release and confirm the version actually running after reboot.
  2. Check the evidence. Review the critical log message, the Flagged marker and the configuration for unknown users, scripts, scheduled tasks, proxies and tunnels.
  3. Contain suspected devices. If evidence suggests compromise, isolate the router and preserve logs and configuration before resetting it.
  4. Rebuild from a trusted baseline. Follow the vendor and CERT guidance; do not blindly restore a complete backup taken from a potentially compromised device.
  5. Rotate from a clean endpoint. Replace reachable credentials only after the management path and device configuration are trustworthy again.

Inventory every secret the router could expose

Scope is configuration-dependent. An affected router could hold or provide a path to administrator credentials, VPN private keys or pre-shared keys, certificates, monitoring credentials, automation tokens, shared authentication material and secrets used by downstream network services. A changed route or tunnel could also allow interception of later administrative traffic.

Build the inventory from actual configuration and access logs rather than rotating every organizational secret indiscriminately. Start with credentials that authorize management or identity, then replace secrets for connected services in dependency order. Revoke old values and verify that monitoring no longer accepts them.

This is the same trust-layer problem seen in our analysis of Fire Ant's Cisco router intrusions: recovery cannot rely on the infrastructure whose integrity is in question.

Move replacement secrets through a separate channel

Incident tickets and team chat should record the owner, reason, approval and completion of a rotation. They should not become permanent plaintext stores for the replacement password or key. Verify the recipient independently, create the new value on a clean endpoint and deliver only the minimum secret needed for the next recovery step.

Secretus can provide a short-lived, one-time path for an authorized operator to transfer a replacement credential or small recovery file without leaving the plaintext in normal email or chat history. It does not clean a compromised router, prove the recipient's identity, replace a password manager or make an infected endpoint safe. The separate channel matters only after people, devices and recovery roles have been verified.

What remains unknown

Neither source gives a global count of compromised devices, identifies the operator behind the activity or describes the data accessed on each affected network. MikroTik's bulletin also does not claim that the Flagged mechanism detects every possible change. Administrators should therefore avoid interpreting a clean marker as proof of safety or assuming that every RouterOS installation was exposed in the same way.

Sources