CISA’s September 10 alert covers a missing-authentication flaw in RouterOS’s bandwidth-test service, CVE-2026-67277, and CVE-2026-86060, an SSH login-path argument-handling bug that can be used to manipulate session privileges. MikroTik published patched releases on September 3: RouterOS 6.49.21, 7.23.4, 7.24.2, and 7.25 beta 3.
The significant detail is that the two CVEs now in CISA’s catalog are part of a wider group of RouterOS issues disclosed by CERT Polska on September 5. CERT Polska has independently confirmed attacks against internet-accessible RouterOS devices, but its public technical account identifies the observed MikroTrick takeover chain as CVE-2026-67276 plus CVE-2026-86060—not CVE-2026-67277 plus CVE-2026-86060. Administrators should not read CISA’s two-entry update as a complete description of the risk or limit their remediation search to those two identifiers.
The active takeover path starts with exposed SSH
CERT Polska says attackers have been exploiting a combination of RouterOS SSH weaknesses to seize full control of devices whose SSH service is reachable from public networks. CVE-2026-67276 is an SSH authentication-bypass flaw: RouterOS failed to compare an entire authorized RSA public key during authentication. CVE-2026-86060 can then elevate privileges through a crafted username handled incorrectly by the SSH login mechanism.
That pairing explains why an organization may face much more than a bandwidth-test crash or isolated information disclosure. CERT Polska says the attacker’s resulting RouterOS session receives full administrative privileges. In practical terms, that places firewall policy, routes, NAT rules, VPN settings, scripts, scheduler tasks, proxy configuration, and local credentials within reach of an intruder.
MikroTik’s own advisory takes a narrower but operationally useful position: most default configurations are not at immediate risk because the vendor’s default firewall setup blocks SSH from the internet. That is only reassurance for devices still operating with the default posture. Any administrator who exposed TCP port 22 for remote support, enabled a broad management rule, inherited an old configuration, or moved a router behind a permissive upstream firewall needs to verify exposure rather than assume the default applies.
The Canadian Centre for Cyber Security separately warned on September 8 that all three CVEs—CVE-2026-67276, CVE-2026-67277, and CVE-2026-86060—were reportedly being exploited. That corroborates the urgency, while the publicly detailed evidence from CERT Polska remains clearest for the SSH chain built around CVE-2026-67276 and CVE-2026-86060.
CVE-2026-67277 is a separate unauthenticated service problem
CVE-2026-67277 affects RouterOS’s bandwidth-test, or btest, service. CERT Polska describes a flaw that lets an unauthenticated connection enter a state intended to be available only after login. An attacker can use it to trigger kernel-memory leakage and a remote denial of service that restarts the device.
The distinction matters for triage. CVE-2026-67277 is not described by CERT Polska as the privilege-escalation half of the known SSH takeover chain. Its technical impact is instead confidentiality exposure and availability loss through btest. CISA’s KEV listing establishes that it has exploitation evidence, but the agency’s alert does not publish the attack details, affected deployment count, or whether the same operators behind the observed MikroTrick campaign used it.
That lack of public detail is a reason to patch it, not a reason to deprioritize it. RouterOS appliances frequently occupy awkward operational territory: they may be considered “network gear” rather than servers, run for years without centralized endpoint tooling, and expose diagnostic or management features that are absent from a standard Windows or Linux vulnerability scan. A remotely restartable edge router can become an availability incident; a memory-disclosure bug can also furnish information useful for another attack.
CERT Polska’s version analysis says CVE-2026-67277 affects RouterOS 6.0.0 through versions below 6.49.21, RouterOS 7.0.0 through versions below 7.23.4, and the 7.24 branch below 7.24.2. Its data also shows that CVE-2026-86060 spans the same principal fixed releases. The stable maintenance target is therefore clear: deploy 6.49.21 on the long-term 6.x track, 7.23.4 on the long-term 7.x track, or 7.24.2 on the stable track. The 7.25 beta 3 build also contains the fix, but beta software should not become the default production answer when supported stable and long-term releases are available.
Patching is necessary, but it does not answer whether a router was already taken over
MikroTik added a post-update detection mechanism that scans the configuration on startup, disables recognized suspicious entries, logs a critical message, and marks the device as “Flagged.” The vendor instructs administrators to check that state and examine their configuration for unknown users, scripts, or changes after updating.
That feature is useful, but it has a sharp limitation that needs to guide incident response: both MikroTik and CERT Polska say a clean Flagged state is not proof the device was not compromised. The scan detects selected known traces. It cannot establish that an attacker left no other persistence, did not modify a trusted account, or did not use the device temporarily to pivot into the network.
CERT Polska identified specific signs from observed activity: failed SSH logins using the username -2, the addition of a user through SSH associated with that string, and a highly privileged account named ops. It also associated successful attacks seen since at least September 2 with one IP address, while naming another used in exploitation attempts. Those are investigation leads, not a complete detection rule. Attackers can change IP addresses, account names, and persistence techniques quickly.
For a router with any of those artifacts—or with unexplained changes to users, scheduler entries, scripts, firewall rules, tunnels, DNS settings, proxy settings, or VPN peers—the proper response is to isolate it, preserve its logs and configuration before resetting it, then rebuild from a known-good configuration. CERT Polska explicitly advises against restoring a full configuration backup from a potentially compromised device. Credentials, SSH keys, VPN secrets, API tokens, and any administrator passwords trusted by the router should be rotated as part of that recovery.
What Windows and network administrators should do today
The devices at risk may not be visible in a Windows patch dashboard, but their compromise can directly affect Windows networks. A RouterOS administrator account can be used to redirect traffic, alter DNS resolution, observe unencrypted flows, cut remote access, or make a compromised router a foothold against domain-connected systems behind it.
The operational order should be straightforward:
- Identify every MikroTik RouterOS appliance, including remote-office routers maintained by third parties or sitting in cloud and colocation networks.
- Verify whether SSH, WWW, WWW-SSL, or the bandwidth-test server can be reached from untrusted networks, including through IPv6 and nonstandard ports.
- Upgrade to RouterOS 6.49.21, 7.23.4, or 7.24.2 as appropriate, then validate the actual running version rather than relying on a completed change ticket.
- Restrict administration to a dedicated management network or a VPN such as WireGuard, and do not leave RouterOS management interfaces exposed directly to the public internet.
- Check RouterOS logs and the Flagged state, then inspect accounts, scripts, scheduler jobs, tunnels, proxy configuration, firewall rules, DNS settings, and recent configuration changes.
- Escalate suspicious systems to incident response and rotate secrets after preserving evidence; an in-place update alone closes the vulnerable path but does not evict a prior intruder.
CISA’s new directive raises the stakes for federal operators
For U.S. federal civilian executive branch agencies, the KEV entries carry more weight than a generic vendor advisory. CISA’s Binding Operational Directive 26-04, issued June 10, changed the federal patching model to prioritize asset exposure, KEV status, exploit automation, and the degree of post-exploitation control. Agencies must monitor KEV changes, report remediation status, and apply the prescribed timeline for the risk category of each asset.
The directive explicitly treats public exposure as a central variable. An internet-reachable RouterOS device with a known exploited path toward administrative control is precisely the kind of asset the new framework intends agencies to find and remediate first. It also requires agencies, in specified situations, to conduct forensic triage for compromise before they patch—not merely report a new version number.
Private-sector organizations are not bound by BOD 26-04, but the priority logic fits this incident. The immediate question is not whether a RouterOS CVE has a high score in a scanner. It is whether a particular router is reachable, whether its SSH or btest services are enabled, whether it is on an affected build, and whether it shows evidence that somebody already used it.
CISA’s addition of CVE-2026-67277 and CVE-2026-86060 puts two RouterOS bugs on the list administrators are expected to treat as active threats. The broader record from MikroTik and CERT Polska adds the operational conclusion: update the router, close public management access, and investigate exposed devices for a compromise that a successful patch cannot reverse.