MikroTik RouterOS Rekey Error Exposes Routers With Open SSH

A RouterOS router with SSH reachable from an untrusted network has another entry path to account for. On September 25, CISA put CVE-2026-67279 on the KEV list. An unauthenticated client can get as far as an SSH session channel and send an exec request. CISA says this flaw can be chained with CVE-2026-86060 for unauthenticated exploitation.

As of October 2, CISA’s September 28 action date has passed. Operators who followed our earlier RouterOS SSH attack coverage should revisit the exposure decision: that attack route used account information, while this rekey route enters the command path before user authentication. CISA lists the new flaw as known exploited; the chain is a described capability, so investigate exposed devices on their own merits.

Rekey crosses the SSH login step

The CERT Polska-assigned CVE record describes the state error precisely. After a client requests an SSH rekey, affected RouterOS builds enter the connection protocol even though nobody attempted user authentication. The server then dispatches an exec request. That gives the unauthenticated client the ability to create, overwrite or reconstruct files in the RouterOS-managed file namespace, including support files with configuration and diagnostic data.

The second flaw, CVE-2026-86060, affects how the SSH login helper handles a username beginning with a prohibited character. CERT Polska says that handling can change the trusted RouterOS policy mask and escalate privileges when an unauthenticated SSH session reaches the helper. Think of the first error as getting through a door before the badge check; the second changes the permissions the next desk assigns.

Fixed builds and exposed management

MikroTik’s September advisory lists first-fixed builds across channels: 6.49.21 for RouterOS 6 long-term, 7.23.4 for RouterOS 7 long-term, 7.24.2 for stable, and 7.25 beta 3 for beta. The CERT Polska CVE records independently name the first three fixes for both flaws. Match each device’s installed build and release channel to its fixed build rather than treating every RouterOS 7 installation as equivalent.

MikroTik says, “Most configurations are not at risk, but upgrading is highly recommended.” Its default configuration blocks SSH from the internet. The urgent exposure check is for routers whose administrators opened SSH to untrusted networks, including a service published through upstream forwarding. Restrict management access to trusted addresses or, as MikroTik recommends, use a VPN such as WireGuard instead of publishing management ports. Make that restriction at the router and verify it from the untrusted side of the path.

The company says RouterOS can mark a compromised device Flagged and write a critical entry in the Log section. After upgrading, inspect that state and review unknown users, scripts and configuration changes even on an unflagged router. Earlier published -2 login patterns describe a different SSH chain; use installed build, reachable SSH and device configuration to scope this newly listed path rather than relying on that pattern alone.

Test the SSH exposure again

Inventory RouterOS versions and release channels, then install the appropriate fixed build on affected routers. Remove untrusted SSH reachability and test the management path from a network outside the trusted address range: the SSH connection should fail there, while your approved management path still works. On updated devices, review the critical Flagged log entry and unknown accounts, scripts or settings; investigate any unexpected change before returning the router to normal service.

The earlier account-information path and the newly listed rekey path lead to the same operational decision: a reachable management service needs both a fixed RouterOS build and a deliberately limited set of callers. Test the access rule from where an untrusted caller would stand, then inspect the router itself for changes that predate the update.