CERT Polska published a warning on 5 September 2026: attackers are gaining full administrative control of MikroTik routers without authentication, against devices with SSH reachable from the internet. The observed attacks date to at least 2 September.

The mechanism is described as a combination of two vulnerabilities. Which two is not stated.

The affected versions

  • 6.0.0 to below 6.49.21
  • 7.0.0 to below 7.23.4
  • 7.24 to below 7.24.2
  • 7.25beta3

MikroTik has published fixed releases across those branches.

Note where that list starts. RouterOS 6.0.0 shipped in 2013. The affected range covers essentially every 6.x device that has not been kept current, which in this product's installed base is a great many — MikroTik hardware is cheap, durable, and frequently deployed by people who set it up once.

The two flaws have names

When this article first ran, neither CERT Polska's warning nor the surrounding disclosure identified the vulnerabilities or explained how they combined, and that gap was the story. It has since been filled.

CERT Polska and MikroTik disclosed 6 RouterOS vulnerabilities on 5 September, 2 of which chain into the attack now called MikroTrick:

CVE-2026-67276, CVSS 9.2 — the SSH authentication bypass. During public key authentication RouterOS validates only the key type and the modulus, not the whole key. An RSA public key is a modulus and an exponent, and the modulus is public by definition: it is sitting in the authorized key. So an attacker who can read an authorised user's public key can present something that matches on the fields RouterOS checks, without ever holding the private key.

CVE-2026-86060, CVSS 9.2 — the escalation. From that pre-authentication state, a crafted username is misread by RouterOS's SSH login helper as a command-line argument, which yields full administrative privileges.

A third, CVE-2026-67277 at 8.8, is a memory disclosure and denial-of-service issue not part of the chain.

Two textbook classes, one after the other

Worth naming what these are, because both are old and both are avoidable.

The first is incomplete verification. The check exists, runs, and returns success — it simply verifies the wrong thing. Validating that a key has the right shape is not the same as validating that the presenter holds the private half, and the whole point of public key authentication is the second one.

The second is argument injection: attacker-controlled text reaching a program's argument list, where a leading dash turns data into an instruction. It is the same class as the shell-metacharacter bugs of the 1990s, moved one layer along.

Neither required a novel technique. What made this severe is that they sit next to each other in the one service organisations deliberately leave reachable.

The timeline is tighter than it looked

Fixes shipped in RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 on 3 September. Exploitation has been observed since at least 2 September — so the fix landed a day after attacks began, and the public warning two days after that.

Reporting puts roughly 122,500 routers exposed.

And the account attackers create is named ops, which is a more useful thing to search for than the log string below, because it is what appears in the user list rather than in a log the device owner may no longer have.

The detection surface is one string

The published indicator for compromise is account-creation log entries containing ssh:-2@, alongside general advice to look for suspicious accounts.

That is a genuinely useful string and it is also the entire published detection surface. It catches an attacker who created an account and did not clean up. It does not catch one who used existing credentials afterwards, cleared the log, or persisted through a script or scheduler entry instead of an account — and on RouterOS there are several places to persist that are not the user list.

If you find nothing, you have found nothing. On these devices that is worth stating plainly, because the log is on the device the attacker controlled. The same problem showed up in the HAProxy implant last week, where the compromised process was also the one writing the record of what it had done.

What to do

  • Patch to 6.49.21, 7.23.4 or 7.24.2 or later, matching your branch. This is the whole mitigation and everything else is a stopgap.
  • Take SSH off the internet regardless. Management interfaces on edge devices do not belong on the public side, before or after this.
  • Search account-creation logs for ssh:-2@, and enumerate every account on every device against what you expect to be there.
  • Do not treat a clean log as clearance. Compare configuration exports against a known-good baseline instead — scheduler entries, scripts, firewall rules, DNS settings and any tunnel configuration you did not create.
  • Check what the router was doing on the network, not just what is on it. A compromised edge device is useful as a pivot and as a traffic vantage point, and neither leaves an account behind.

What is not established

  • Whether the other four disclosed flaws are being exploited. CERT Polska's confirmation covers the MikroTrick pair only, though CISA has since listed the bandwidth-test flaw as exploited as well.
  • Whether either was a zero-day at the time of the first observed attacks. That remains unverified.
  • How many devices are compromised. The figure above counts routers with SSH reachable from the internet, not routers that fell.
  • Who is behind it, or what the routers are being used for.
  • Whether the published indicator is complete. One string is what has been released; nothing says it is the only artefact.