MikroTik RouterOS Exploit Chain and Related Vulnerabilities (Actively Exploited)

Summary

CERT Polska has disclosed six vulnerabilities in MikroTik RouterOS. Two of them : CVE-2026-67276 (SSH authentication bypass) and CVE-2026-86060 (SSH privilege escalation via crafted username) — form an exploit chain named MikroTrick that gives an unauthenticated remote attacker full administrative control of a RouterOS device whose SSH service is reachable on the network. The remaining four cover kernel memory disclosure and DoS in the bandwidth-test service, X.509 certificate validation flaws enabling TLS impersonation, an unauthenticated file read/write path via SSH rekey, and an unauthenticated file read via WebFig. All six are fixed in the same September 2026 release. Active exploitation of MikroTrick against internet-exposed RouterOS devices has been confirmed and observed since at least 2 September 2026.

Impact

Exploitability signals: CVSS 9.2 for each half of the MikroTrick chain · active exploitation confirmed by CERT Polska with attacker IPs and post-compromise artefacts identified · unauthenticated, remote, no user interaction · fixes were reverse-engineered from public patches within days of release.

Successful MikroTrick exploitation yields full administrative control of the RouterOS device. On institutional deployments that means: the device’s own configuration (including WPA2/WPA3 keys, VPN pre-shared keys, RADIUS shared secrets, SNMP communities, and stored SSH keys), any traffic passing through it (interception, redirection, mirroring), the ability to plant persistence via users/scripts/schedulers/tunnels, and a foothold for lateral movement into the wider network. Any institution operating RouterOS devices in any role should treat this advisory as in-scope.

Affected systems

MikroTik RouterOS on any device (RouterBOARD, CCR, CHR, CRS, hAP, wAP, and others) running:

• 6.x Long-term — versions 6.0.0 through 6.49.20 (fixed in 6.49.21)
• 7.x Long-term — versions 7.0.0 through 7.23.3 (fixed in 7.23.4)
• 7.x Stable — versions 7.24 and 7.24.1 (fixed in 7.24.2)
• 7.x Testing — fixed in 7.25beta3

Action

1. Update RouterOS immediately to a fixed release on your train (7.24.2, 7.23.4, or 6.49.21). All six vulnerabilities are addressed in a single upgrade.
2. Check for indicators of compromise on every device, whether patched or not. CERT Polska has published the following artefacts of the MikroTrick attacks observed to date:
   • Log entries matching: login failure for user -2 from via ssh user added by ssh:-2@
   • Presence of a highly privileged user named ops.
   • SSH connections from 82.192.72.4 (confirmed successful takeovers) or 103.102.31.18 (exploitation attempts). Absence of these artefacts is not proof the device is clean — they cover only the specific attack campaign observed so far.
3. Check the “Flagged” status after upgrading. RouterOS 7.24.2/7.23.4/6.49.21 introduced a startup scan that looks for known signs of unauthorised configuration changes and sets a Flagged marker. Run: /system/device-mode/print and inspect the flagged field. If set, treat the device as compromised and proceed to step 5. Again, absence of the flag does not guarantee integrity — the scan detects only known traces.
4. Audit every device’s configuration for changes you did not make, in particular: unknown user accounts (especially admin-privileged), unfamiliar scripts under /system script, unexplained tasks under /system scheduler, unexpected SOCKS or Web proxy entries, and tunnel interfaces (L2TP, PPTP, IPIP, GRE, EoIP, WireGuard) that don’t match your baseline.
5. If compromise is indicated (Flagged marker, matching IoCs, unknown accounts or scripts, or the device was internet-reachable on SSH and unpatched since 2 September 2026):
   • Isolate the device from the network before doing anything else.
   • Export logs and the current configuration to preserve evidence — do this before any reset.
   • Reset the device to factory defaults.
   • Reconfigure from a trusted baseline you can verify, not a backup taken from the potentially compromised device.
   • Rotate every credential the device held or could reach: local admin passwords, RADIUS shared secrets, VPN pre-shared keys, SNMP communities, WPA keys, stored SSH keys, and any API credentials.
   • Report the incident to GARNET CSIRT.
6. Reduce management-plane exposure, whether patched or not. RouterOS management services — SSH, WWW, WWW-SSL, WinBox, API, and the bandwidth-test server — should be reachable only from institutional management networks or administrative VPN ranges, not from the public internet. Use /ip service and firewall input rules to enforce this. This is defence in depth, not a substitute for patching.
7. If you cannot patch immediately, as a temporary measure: disable SSH, WWW/WWW-SSL, and bandwidth-test on WAN-facing interfaces; and do not use the RouterOS SSH or TLS clients (/system ssh, /system ssh-exec, outbound TLS features) against untrusted hosts or over untrusted paths, since CVE-2026-67278 lets a network-position attacker impersonate arbitrary TLS servers to an unpatched device.

Think a system in the community is affected or compromised?Report an incident