MikroTik RouterOS SSH flaw added to CISA KEV as part of unauthenticated "MikroTrick" chain

CISA has added CVE-2026-67279, a MikroTik RouterOS flaw, to its Known Exploited Vulnerabilities catalog, with a remediation due date of 28 September 2026 [1]. The catalog classifies it as improper enforcement of behavioral workflow: a client that has not authenticated can get the SSH service to accept a session channel and take a command-execution request — that is, act before authentication has completed [1].

On its own that is a protocol state problem. The reason it matters is the second half. CISA notes the flaw can be chained to reach unauthenticated exploitation of CVE-2026-86060 [1]. Reporting on the chain, which CERT Polska has named MikroTrick, describes CVE-2026-86060 as an argument-injection bug in the RouterOS login process, and the combined result as full administrative control of an internet-exposed router with no password, no SSH key and no completed authentication [2].

The KEV entry records known ransomware use as “Unknown” [1]. Two gaps in our own enrichment data are worth stating plainly. First, it returned no CVE severity record for this identifier, so the computed severity for this post is none (no CVE data) — treat that as an absence of scoring data, not as a judgement about impact. Second, our enrichment marks the CVE as not actively exploited, which contradicts its presence in the KEV catalog. We are going with the catalog, which is the authoritative source on that question [1], but the discrepancy is unreconciled.

Who is affected

Any MikroTik RouterOS device reachable over SSH is the population to worry about. The public reporting frames the attack as targeting internet-exposed routers [2], and CISA’s required action explicitly puts the burden on asset owners to evaluate each asset’s internet exposure [1].

The sources available to us do not name the affected RouterOS version ranges, the branches that contain a fix, or a vendor advisory. That is a load-bearing gap: without it, “apply the vendor update” is the only accurate instruction we can give, and you will need to confirm the fixed release directly with MikroTik.

For US federal civilian agencies, the KEV listing pulls this into BOD 26-04, which CISA references in the entry along with its forensics triage requirements; the entry also states that where mitigations are unavailable, use of the product should be discontinued [1].

How the chain works, as far as the sources go

Both halves live in SSH. The first flaw is a state-machine problem — the service will accept a channel and a command request from a client that has not finished authenticating [1][2]. The second is argument injection in the login path [2]. CISA states only that the first can be chained to achieve unauthenticated exploitation of the second [1], and the reporting states only that the two are combined [2]. Neither describes the mechanical linkage, so how attacker-controlled arguments reach the login path from a pre-authentication position is our inference, not a documented step.

That is the extent of the mechanism our sources describe. We have no exploit details, no indicators of compromise, and no payload description. One reporting detail is incomplete: the coverage we have refers to attack logs, but the sentence is truncated in the material available to us, so we cannot state when observed activity began [2]. Do not read a date into that.

What to do

• Take RouterOS SSH off the internet now. This is the fastest mitigation available and it does not depend on knowing the patched version. Restrict the SSH service to a management VLAN or VPN, or disable it on WAN-facing interfaces.
• Confirm the fixed RouterOS release with MikroTik and upgrade. CISA’s required action is to apply vendor mitigations [1]. Verify the target version against the vendor’s own advisory rather than a third-party summary.
• If you are in scope for BOD 26-04, work to the 28 September 2026 due date and follow CISA’s forensics triage requirements referenced in the KEV entry [1].
• Triage before you wipe. Because the chain is reported to yield admin access without authentication [2], a patched device is not automatically a clean device. Capture configuration and logs first.
• Review router configuration for changes you did not make. Unexpected admin users, SSH keys, scheduled scripts, new tunnels, proxy or SOCKS services, and firewall rule edits are all worth checking on any device that was exposed. These are prudent checks, not published indicators.
• Rotate credentials and keys on any device that was reachable over SSH, and on anything that trusted it.
• Inventory your edge. Scan your own address space for reachable RouterOS management services rather than relying on the intended configuration.