MikroTrick: MikroTik RouterOS Flaws Are Hijacking Internet-Exposed Routers

CERT.PL: the MikroTrick chain turns exposed SSH into router admin

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 give an attacker full administrative control of the router. All it takes is an SSH service exposed to the internet.

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. It has 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 a missing marker does not mean the router is clean.

About 122,500 MikroTik devices have SSH on the internet

A router controls traffic for every network behind it. 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.

Shadowserver counted roughly 122,500 MikroTik devices with SSH exposed to the internet as of September 5. Not all of them are vulnerable. The number still shows how many RouterOS boxes face the internet, and an MSP, ISP or distributed enterprise may have many sitting 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. Search local logs and controls for them. Not finding them does not rule out compromise.

Upgrade, close public SSH, and look for the ops account

• 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.
• Check the vendor’s detection warning. A startup warning or a disabled malicious entry is useful evidence. A clean startup does not prove the device was never accessed. Correlate router evidence with upstream firewall, authentication, and endpoint telemetry.

Sources

• 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

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].