Skip to main content
DNS Benchmark Pro Real-time DoH latency analysis
Engine ready

DNS Security

DNS Security Alert: MikroTik Routers Hijacked

Published September 9, 2026 · DNS Benchmark Pro Editorial · Reading time: 6 minutes

TL;DR — This is a DNS security incident wearing a routing costume. CERT Polska disclosed six RouterOS vulnerabilities on 5 September 2026; two of them chain into an unauthenticated full-device takeover the team named MikroTrick. CVE-2026-67276 (CVSS 9.2) bypasses SSH public-key authentication, and CVE-2026-86060 (CVSS 9.2) escalates that session to full administrator. MikroTik shipped fixes on 3 September — 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 — but exploitation was already running by 2 September, making it a genuine zero-day vulnerability. Shadowserver counted 122,500+ RouterOS devices with SSH reachable from the internet. Patch, then hunt for SSH user -2 and an unexplained ops account.

Router compromises get filed under networking, not DNS security, and that filing error is exactly what makes them profitable. An attacker who owns the edge device owns the DHCP options it hands out, the forwarder addresses it advertises, and the NAT table every internal query traverses. Full administrative control of a RouterOS box is, in practice, a licence to rewrite name resolution for everything behind it — silently, persistently, and without touching a single endpoint.

What the MikroTrick chain actually does

CVE-2026-67276 is the interesting half. RouterOS validated an offered SSH public key by comparing the key type and the RSA modulus — not the whole key. An attacker who already knows a valid username and the public modulus associated with it can construct a different key that passes that comparison and authenticate without ever possessing the private key. Public keys are, by design, public; the modulus is not a secret and was never meant to be one.

CVE-2026-86060 supplies the escalation. RouterOS mishandled SSH usernames beginning with a disallowed character, and a crafted username caused its login helper to interpret the string as a command-line argument rather than an identity. The result is a session with full administrative privileges. Chained together, the two flaws convert an exposed SSH port into unauthenticated root-equivalent access with no credential, no phishing and no user interaction.

A third flaw, CVE-2026-67277 (CVSS 8.8), sits in the bandwidth-test service and lets unauthenticated connections reach a state reserved for logged-in users; combined with a leak of uninitialised packet-buffer data and an integer underflow in size validation, it can expose kernel memory or crash the device into a restart. Three lower-severity issues affect the SSH client, X.509 certificate handling and the WebFig management interface. CERT Polska found the set using large language models under a government research programme — a detail worth noting for anyone still assuming that AI-assisted vulnerability discovery is a future problem for IT security teams rather than a present one.

The disclosure timeline is the real story

MikroTik published patched builds on 3 September. CERT Polska disclosed on 5 September. But logs on a Polish administrator forum, corroborated by CERT Polska’s own incident data, show exploitation attempts from 2 September — before the patches existed publicly. Researcher Costin Raiu’s reading is blunt: someone knew the fixes were coming and moved first, at scale.

That inversion matters operationally. The standard assumption is that patch release starts the clock and attackers begin reverse-engineering the diff. Here the attackers were ahead of the diff. Any device exposed on 2 September should be treated as potentially compromised regardless of how quickly it was patched afterwards.

DNS security check: verified DNS Benchmark Pro capture showing DNS server performance and validated resolver responses, used to confirm that a MikroTik router is not silently redirecting name resolution to an attacker-controlled DNS server
Verified, unmodified capture from the DNS Benchmark Pro engine. After a suspected edge-device compromise, the fastest independent check is whether the resolvers your network actually reaches are the ones you configured — which is why DNS server performance testing doubles as a tamper check on the router in front of it.

Why this is a DNS security problem, not just a patching one

Administrative control of RouterOS grants control of the /ip dns configuration, the DHCP server’s advertised resolver list, firewall rules and NAT. Four abuses follow directly, and none of them require malware on a single endpoint.

The mitigation that survives an edge compromise is encrypted resolution terminating somewhere the router cannot influence. A client using DNS over HTTPS to a pinned, authenticated endpoint does not care what the local router advertises, because the resolver identity is validated by TLS rather than by DHCP. That is the single strongest argument for encrypted DNS in a small-office or branch topology, and it is an availability argument as much as a privacy one.

Detection: what to look for tonight

CERT Polska and Raiu published unusually usable indicators. Failed authentication attempts appear with the username -2, which is not a valid account and should never appear in a healthy log. Successful exploitation shows in /system history as ssh:-2@<IP>, typically followed immediately by a configuration action: user creation, SSH key addition, firewall change, or enabling a proxy or tunnel. The creation of a highly privileged account named ops is a confirmed indicator in observed intrusions. Known source addresses are 82.192.72.4 and 103.102.31.18.

The important caveat, in Raiu’s words, is that absence of the -2 entry proves nothing: logs roll over, and attackers clean them. Treat any unexplained configuration change in the affected window as compromise until disproved — and pay particular attention to DNS settings, which are the change an administrator is least likely to notice.

Chart from an earlier release of the DNS Benchmark Pro network diagnostic tool comparing DNS over HTTPS response times and network latency across public resolvers, referenced in DNS security analysis of the MikroTik RouterOS MikroTrick exploit chain
Unmodified capture from the DNS Benchmark Pro engine as it stood in August 2026. Correction (15 August 2026): the release that produced this chart timed opaque browser requests and did not verify that a response was a valid DNS answer, so the figures shown may include HTTP errors and unreadable replies counted as fast responses. They should not be relied on. The engine was rebuilt to validate every response; see the current methodology. The underlying point — that comparing the whole field beats trusting whatever the router hands you — still holds.

What to do this week

Industry impact: the edge is unmanaged server infrastructure

MikroTik hardware is popular because it delivers carrier-grade routing at commodity prices and runs for years untouched. That durability is the exposure: 122,500 devices with SSH facing the internet is a population that patches slowly, if at all, and the long tail of ISP CPE, branch offices and small-business racks will still be exploitable well into 2027.

For enterprise architects the lesson generalises beyond one vendor. Edge routers are server infrastructure — they run a general-purpose operating system, hold credentials, and terminate management protocols — but they are almost never inventoried, patched or monitored to the standard applied to servers or to cloud security posture. The same asymmetry we noted in the Chrome V8 zero-day disclosed four days earlier applies here: organisations can quote their server patch compliance to a decimal point and cannot say how many RouterOS boxes they operate.

Until that changes, the practical defence is layered and boring. Keep management planes off the public internet, keep the resolver path independent of the devices in front of it, and measure what your network actually resolves rather than assuming it matches the configuration you wrote. Good DNS security starts with knowing which server answered.

Sources: CERT Polska, “Critical vulnerabilities in MikroTik RouterOS are being actively exploited” (5 September 2026); MikroTik security bulletin, September 2026; Help Net Security, “Hackers exploit RouterOS flaws to hijack MikroTik devices without authentication” (7 September 2026); Security Affairs, “Your MikroTik Router May Already Be Compromised” (6 September 2026); Costin Raiu, “MikroTik SSH 0day exploitation in the wild”; Shadowserver Foundation scan data (5 September 2026); NVD entries for CVE-2026-67276, CVE-2026-86060 and CVE-2026-67277. This article is independent editorial analysis and is not affiliated with or endorsed by MikroTik or CERT Polska.