MikroTrick: MikroTik RouterOS Flaws Are Hijacking Internet-Exposed Routers

What Changed

Poland’s CERT.PL is warning that attackers are actively exploiting a chain of MikroTik RouterOS vulnerabilities it calls MikroTrick. The chain combines CVE-2026-67276, an SSH authentication bypass, with CVE-2026-86060, an SSH privilege-escalation flaw. Together, they can turn an internet-exposed SSH service into full administrative control of the router.

CVE-2026-67276 stems from incomplete validation of RSA public keys. An attacker who knows a username and that user’s public-key modulus can craft a different key and authenticate without the legitimate private key. CVE-2026-86060 abuses specially crafted usernames to manipulate the SSH session and obtain full privileges.

CERT.PL also identified CVE-2026-67277 in the RouterOS bandwidth-test service. It can allow unauthenticated kernel-memory disclosure or remotely crash/restart a router. The flaws were fixed in RouterOS 7.25beta3, 7.24.2, 7.23.4, and 6.49.21, among the listed fixed branches. MikroTik says not every configuration is affected, but it withheld technical detail to give operators time to update.

The fixes add a startup compromise-detection mechanism that looks for known unauthorized configuration changes, disables malicious entries, and logs a critical warning. CERT.PL cautions that no marker is not a clean bill of health.

Why This Matters Operationally

Routers are control points, not ordinary endpoints. An attacker with administrative access can alter DNS, routing, firewall rules, VPN settings, users, NAT, traffic capture, and management access. They can use the device as a durable foothold or as a trusted location from which to reach the networks behind it.

The exposure is measurable. Shadowserver counted roughly 122,500 MikroTik devices with SSH exposed to the internet as of September 5. That count is not the number of vulnerable devices, but it shows why a device-by-device assumption is unsafe. An MSP, ISP, or distributed enterprise may have many RouterOS instances outside its normal server patch inventory.

CERT.PL’s indicators include the log entry login failure for user -2 from via ssh, a related user added by ssh:-2@ entry, and the presence of a highly privileged ops account. It also lists 82.192.72.4 as linked to confirmed successful attacks and 103.102.31.18 as an observed exploitation source. These should be searched in local logs and controls, but an absent indicator does not rule out compromise.

What Defenders Should Verify First

• Inventory by RouterOS version and exposure. Pull the version, model, management interfaces, and SSH/WWW/WWW-SSL/bandwidth-test exposure from every router. Include branch offices, customer sites, lab devices, and equipment managed by a service provider.
• Upgrade to a fixed branch. Move each device to the vendor’s fixed RouterOS release for its supported branch, including 7.24.2, 7.23.4, or 6.49.21 as applicable. Verify the running version after reboot and retain the change record.
• Restrict the management plane now. Until upgrades are complete, disable internet-facing SSH where possible or allow it only from a trusted management network. Restrict WWW/WWW-SSL and bandwidth-test services as well. Do not rely on an obscure port as protection.
• Search for MikroTrick indicators. Review logs for user -2, ops, and user added by ssh:-2@ , and check whether either reported IP appears in logs, firewall records, DNS data, or configuration history. Look for new users, changed keys, altered services, new firewall/NAT rules, DNS changes, and unexpected scheduler entries.
• Preserve the current configuration. Export the configuration and relevant logs before making large changes. Keep a known-good backup separate from the device, because an attacker with administrative access may alter local recovery material.
• Assume compromise if unauthorized changes are found. Isolate the router, preserve evidence, factory-reset it, and rebuild from a trusted configuration. Rotate passwords, SSH keys, VPN secrets, certificates, and any credentials that traversed or were stored on the device. Review the networks behind it for follow-on access.
• Validate the vendor’s detection warning. A startup warning or disabled malicious entry is useful evidence; a clean startup is not proof that the device was never accessed. Correlate router evidence with upstream firewall, authentication, and endpoint telemetry.

Source Context

• BleepingComputer: Hackers exploit new MikroTik RouterOS flaws to hijack routers
• CERT.PL advisory on the MikroTrick exploitation chain
• MikroTik RouterOS fixed releases and security guidance

The practical test is simple: every RouterOS device with public SSH needs an owner, a fixed version, restricted management access, and a configuration you can trust.

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].