ZoomEye count puts 8.09M RouterOS devices online, with 9,560 answering on SSH

An analysis published on dev.to estimates that 8,085,997 devices running MikroTik's RouterOS are indexed as internet-visible, and that 9,560 of them answer on SSH — the exact precondition behind the recently disclosed MikroTrick exploitation chain.

The vulnerability background

According to the dev.to post, CERT Polska disclosed six MikroTik RouterOS vulnerabilities in September 2026 and reported that two of them were already being combined in attacks. The first, CVE-2026-67277, is a missing authentication check for a critical function, categorised under CWE-306. The second, CVE-2026-86060, involves improper neutralization of argument delimiters, categorised under CWE-88. Chained together, the two flaws allowed unauthenticated attackers to gain full administrative control of devices whose SSH service was reachable from the internet. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 10 September 2026.

What the measurement shows

The analysis is based on ZoomEye queries collected on 20 September 2026. A fingerprint query for the RouterOS operating system returned 8,085,997 indexed assets, representing the broad population of internet-visible RouterOS deployments — routers, wireless access points and other network equipment running the OS. A second query combining the RouterOS fingerprint with the SSH service returned 9,560 results, which the post identifies as the figure directly relevant to the reported exploitation.

The gap between the two numbers is itself informative. Roughly one in eight hundred indexed RouterOS assets answers on SSH, suggesting that most deployments either do not enable SSH, do not expose it to the internet, or are not fingerprinted on that service. Because scanning coverage and fingerprinting accuracy both constrain the result, the analysis treats the 9,560 figure as a floor for the exposed population rather than a ceiling.

How to read the numbers

The post applies two cautions to both figures. First, an indexed asset is not necessarily a vulnerable asset: the fingerprint identifies the operating system, not the firmware version, so a patched RouterOS device appears in the same count as an unpatched one. Second, exposure is not the same as compromise — an internet-reachable SSH service is a precondition for the reported chain, not evidence that exploitation occurred, and determining that requires log review on the device itself.

What the numbers do establish, according to the analysis, is the size of the population needing attention. Nearly ten thousand internet-visible RouterOS devices answering on SSH is a manageable inventory for a coordinated response, and simultaneously a large enough target set to make automated scanning worthwhile for an attacker.

A practical verification workflow

For organisations managing RouterOS equipment, the dev.to post suggests a specific order of operations:

• Enumerate the RouterOS devices the organisation owns, including equipment managed by branch offices and contractors.
• Determine which of those devices expose SSH to the internet, since that is the exposure the reported chain depended on.
• Compare firmware versions against MikroTik's fixed release guidance for the deployed branch.
• Review user lists and login logs for accounts or successful authentications the organisation did not create.
• Inspect firewall rules, scheduled scripts and forwarding entries for unauthorised changes.

The analysis notes that the firmware and log-review steps are where the vendor advisory and the exposure measurement meet: patching removes the vulnerability, while log review establishes whether the exposure was actually used.

Why it matters

Network equipment is notoriously difficult to inventory because it is often managed by separate teams, deployed at remote sites, and replaced infrequently. An external exposure measurement offers an independent check on internal records — it answers whether a device is visible from the outside, a property most organisations do not track.

For RouterOS specifically, repeating the measurement over time quantifies whether remediation is real. If the count of RouterOS assets answering on SSH declines after an advisory, that is evidence patching is happening. If it does not, the exposure persists regardless of how many internal tickets were closed.