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.

What is not being said

Neither CERT Polska's warning nor the surrounding disclosure identifies the two vulnerabilities, assigns CVEs to them publicly, or explains how they combine to produce unauthenticated administrative access.

There is a reasonable case for that. A chain that yields pre-auth admin on an internet-facing router, against an installed base that updates slowly, is close to the worst thing to hand out a recipe for. Every hour of delay in publishing the mechanism is an hour more of patching before the exploit becomes commodity. Vendors and CERTs make this trade deliberately and they are often right.

There is also a cost, and it lands entirely on defenders.

Without knowing the mechanism, you cannot answer the questions you actually need answered:

  • Does the chain require SSH specifically, or is SSH the observed path into something broader?
  • Do the compensating controls you already have — source restrictions on the SSH service, a firewall rule, a non-default port — break the chain or merely reduce exposure?
  • Is a device that was internet-facing but has since been firewalled still at risk from something already planted?
  • Does an unaffected version number actually mean unaffected, or untested?

"Patch, and if you cannot patch, take SSH off the internet" is good advice and probably sufficient. It is not the same as being able to assess your own estate, and organisations with real change control need the second thing to justify the first.

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

  • Which two vulnerabilities form the chain, or whether CVEs have been assigned.
  • Whether either was a zero-day at the time of the first observed attacks. That remains unverified.
  • How many devices are compromised, or how many are exposed. No count has been published.
  • 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.