MikroTik RouterOS suffers from a chain of two critical SSH-related vulnerabilities: CVE-2026-67276, an SSH authentication bypass caused by incomplete RSA public key validation, and CVE-2026-86060, an SSH privilege escalation via specially crafted usernames. Exploitation allows attackers to log in without the legitimate private key and gain full administrative privileges. A third flaw, CVE-2026-67277, impacts the bandwidth-test service, enabling unauthenticated kernel memory leaks or remote device crashes. These vulnerabilities are actively exploited in the wild, as confirmed by Poland's CERT, which discovered them with AI assistance. MikroTik patched these issues in RouterOS versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21, and introduced compromise detection features. Indicators of compromise include specific SSH log entries and presence of unauthorized privileged accounts. The advisory stresses that absence of compromise markers does not guarantee device integrity. Mitigation includes applying patches, isolating compromised devices, and restricting external SSH and related services until updates are applied.

Successful exploitation of CVE-2026-67276 allows attackers to bypass SSH authentication without the legitimate private key, gaining unauthorized access. CVE-2026-86060 enables privilege escalation to full administrative rights on the router. Together, these allow attackers to take full control of MikroTik routers with exposed SSH services. CVE-2026-67277 can cause memory leaks or remote crashes, potentially disrupting router availability. Active exploitation has been observed, with attackers confirmed to have compromised devices. This can lead to unauthorized configuration changes, persistent control, and potential network compromise.

MikroTik has released official patches in RouterOS versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21 that fix these vulnerabilities and add compromise detection mechanisms. Users should apply these updates immediately. The vendor notes not all configurations are affected, but details were withheld to allow time for patching. If compromise is suspected, isolate the device, preserve logs and configurations, perform a factory reset, and rebuild from trusted configurations while rotating all credentials. Until patches can be applied, restrict or disable externally accessible SSH, WWW/WWW-SSL, and bandwidth-test services. Avoid using built-in SSH clients and outbound TLS connections over untrusted networks. The absence of compromise indicators does not guarantee device integrity, so proactive patching and mitigation are critical.