MikroTrick: 122,500 exposed routers, and a patch that does not evict the intruder

The chain

CERT Polska published on 5 September 2026, describing six vulnerabilities in MikroTik RouterOS of which three are material ^[1]. CVE-2026-67276 is an authentication bypass arising from incomplete RSA public key verification in the SSH service. CVE-2026-86060 is a privilege escalation in which a username beginning with a disallowed character is mishandled by the SSH login helper, permitting modification of the trusted RouterOS policy mask ^[1][6][7]. CVE-2026-67277 is missing authentication in the bandwidth-test service, giving kernel memory disclosure and denial of service ^[1][8].

CERT Polska named the first two, chained, MikroTrick. Together they allow an attacker to take full control of a device without authentication wherever SSH is reachable from public networks ^[1][2][8]. No exploitation detail is reproduced here; the class is the useful part. An authentication bypass chained to a privilege model that can be rewritten from the login path leaves nothing for a password policy to defend.

The timeline runs the wrong way

MikroTik published its advisory on 3 September with fixes in RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 ^[10]. CERT Polska's disclosure followed on 5 September ^[1]. Exploitation was confirmed from 2 September, before any patch existed ^[2][9][11].

Security Affairs, reporting Costin Raiu, records exploitation attempts documented on a Polish security forum from that date and notes this suggests attackers had advance knowledge ^[9]. That ordering removes patch latency as an explanation. For the window that mattered, the only available control was not being reachable.

CISA added CVE-2026-86060 and CVE-2026-67277 to the Known Exploited Vulnerabilities catalogue, with a federal remediation deadline of 13 September ^[3]. Most reporting records the addition on 10 September ^[3][5]; one tracker places both in its 16 September update window ^[12]. CVE-2026-86060 additionally requires forensic triage under Binding Operational Directive 26-04 ^[4].

Worth noting: CVE-2026-67276, the authentication bypass that forms the first half of the chain, does not appear among the catalogued entries ^[3][4]. An organisation triaging strictly from the catalogue will patch the escalation and the bandwidth-test flaw without ever reading about the bypass.

The published numbers do not agree

CERT Polska rates CVE-2026-86060 at 9.2 and CVE-2026-67277 at 8.8 ^[1], and Triskele Labs repeats those figures ^[2]. One KEV tracker lists 9.8 and 8.2 for the same pair ^[12]. A commercial CVE aggregator published a uniform 9.5 across its entire actively-exploited set for the day, matching no vendor or CERT figure and suggesting a synthesised score rather than a reported one.

Fixed versions are also inconsistent. MikroTik and CERT Polska both give 7.23.4 ^[10][1]; Security Affairs lists 7.23.5 ^[9]. Take the vendor advisory and nothing else for version decisions.

MikroTik's own framing is materially softer than the CERTs'. Its advisory states that most configurations are not at risk while recommending the upgrade, and assesses limited immediate risk to home users ^[10]. That is defensible, since the chain requires SSH to be reachable. It is also the sentence most likely to be read downstream as permission to defer.

Exposure, and who is exposed

The Shadowserver Foundation identified roughly 122,500 RouterOS devices with SSH exposed to the internet on 5 September ^[11][2]. The distribution is concentrated: Brazil 11,300, the United States 7,100, Indonesia 7,100, Czechia 6,300 and Ukraine 5,100 ^[11].

Indonesia at 7,100 puts Southeast Asia in the top tier of exposure, and that is the figure regional defenders should sit with. MikroTik is widely deployed by regional internet providers, wireless ISPs and small operators precisely because it is inexpensive and capable. These are not edge devices in front of one organisation. They carry other people's traffic, terminate other people's tunnels and hold other people's routes.

Exposure is not the same as vulnerability, and not every reachable device runs an affected configuration ^[11][10]. But the population is large, largely unmanaged, and in most cases nobody is reading its logs.

Patching is not the whole job

The compromise indicators are specific and cheap to check ^[1][9][5]:

• A log entry reading login failure for user -2, and history entries attributed to ssh:-2 at an external address ^[1][9][7].
• An account named ops, or any unexpected highly privileged account ^[1][2][9].
• A Flagged marker in device status, which the patched releases surface ^[1][10].
• Configuration changes touching users, SSH keys, firewall rules, proxies or tunnels ^[9].
• Connections involving 82.192.72.4 or 103.102.31.18 ^[1][2][5].

Raiu's caution is the operative one: do not conclude a device is safe merely because no such login failure appears, since logs may have rolled over or been cleaned ^[9]. Patching closes the exposure. It does not evict an operator who already holds administrative control and has had time to add accounts, keys, scripts and firewall rules ^[9][2].

CERT Polska's compromise path is explicit: isolate the device, preserve logs and configuration, factory reset, and reconfigure from a trusted backup ^[1]. The phrase carrying the weight is trusted. Restoring the device's own saved configuration reinstates whatever was written into it.

What to do

• Upgrade to 6.49.21, 7.23.4, 7.24.2 or later, per the vendor advisory rather than a secondary list ^[10][1].
• Take SSH off the internet. Where remote management is needed, restrict it to trusted ranges or reach the device over WireGuard, which is MikroTik's own recommendation ^[10].
• Restrict WWW, WWW-SSL and the bandwidth-test service as well; the third flaw's attack surface is the bandwidth-test daemon, not SSH ^[1][8].
• Hunt with the indicators above before concluding the estate is clean, and treat a rolled log as an unanswered question rather than an all-clear ^[9].
• Rotate everything the device held: local accounts, SSH keys, VPN secrets, RADIUS credentials and SNMP community strings.
• If you run these at scale, manage the fleet as a population rather than a set of devices. The three-day federal deadline ^[3] is a fair proxy for how long an internet-facing router stays untouched.

Domain view

The shape matches the appliance exploitation this desk covered on 14 September: the device under attack is infrastructure rather than an application, exploitation preceded public warning, and the patch does not close the incident.

Two things make this case worse. Exploitation began before a fix existed, so no patching cadence however disciplined would have helped; only reduced exposure would have. And the affected population is not enterprise-managed. A firewall management centre has an owner who reads vendor advisories and has a maintenance window. A large share of 122,500 exposed routers has neither.

That asymmetry is where the residual risk sits, and no amount of patching faster resolves it. For the regional providers holding several thousand of these devices, the question worth answering this week is not whether the fleet is patched. It is whether anyone would be able to tell, from the logs that still exist, if it had been taken in the first week of September.