Routers Under Attack Since the Second of September

CERT Polska published a warning on 5 September that vulnerabilities in MikroTik RouterOS are being actively exploited. Six issues are covered, three of them severe: CVE-2026-67276, an SSH authentication bypass scored 9.2; CVE-2026-86060, an SSH privilege escalation also at 9.2; and CVE-2026-67277, a memory disclosure in the bandwidth-test service at 8.8. Fixed builds are 7.25beta3, 7.24.2, 7.23.4 and 6.49.21. The observed attacks target devices whose SSH service is reachable from the internet, and CERT Polska notes that successful ones so far have originated from a single address, 82.192.72.4, and have been occurring since at least 2 September. Its advice is to update immediately and then to check logs and configuration for unauthorised changes.

That last instruction is the one most often skipped and the one that matters most here. An authentication bypass chained to a privilege escalation means an attacker who reached the device before the patch already has whatever they wanted, and updating afterwards evicts nobody. On a router the durable artefacts are configuration rather than files: a scheduler entry, a new user or SSH key, a changed DNS server, a SOCKS proxy quietly enabled, a firewall rule with an innocuous comment, a NAT rule pointing somewhere it did not before. All of these survive a firmware update, which is why the post-patch review is the actual remediation.

The wider pattern is that network edge devices have become the preferred initial access route into industrial and small-business networks, and MikroTik's installed base makes it a recurring example. These devices sit outside whatever asset inventory the organisation maintains, are frequently installed by a contractor and then forgotten, rarely appear on a patch schedule, and are by definition reachable. A single exposed management service on one of them is a better entry point than any phishing campaign.

For anyone with these in the field — and industrial sites use them widely for remote connectivity — the sequence is: update to the fixed builds; remove SSH, Winbox and the web interface from the public interface entirely rather than restricting them by rule; check for unexpected users, SSH keys, scheduled scripts, changed DNS, and altered firewall or NAT rules; and rotate credentials on the assumption that anything reachable before 2 September may have been read. It is also worth treating the single attacking address as a detail rather than a boundary: a published advisory with proof-of-concept-grade detail reliably produces broader scanning within days, and the exposure that mattered was never the specific source.