CVE-2026-67277 and the MikroTrick Chain: When Two Flaws Become One Attack

Security advisories usually arrive one CVE at a time. Attackers rarely work that way. The MikroTrick activity against MikroTik RouterOS is a reminder that two moderate findings can combine into a single severe outcome, and that defenders who triage each CVE in isolation may miss the chain in front of them.

The two halves

MikroTrick pairs CVE-2026-67277 with CVE-2026-86060. The first is a CWE-306 missing-authentication flaw in RouterOS, reachable through the SSH management service. The second is a CWE-88 argument-delimiter neutralization flaw, a class of defect where input intended as data is instead interpreted as control syntax. CERT Polska documented the combination and confirmed it was being used in the wild, with exploitation observed from 2026-09-02 and a public warning on 2026-09-05. CISA added CVE-2026-67277 to the Known Exploited Vulnerabilities catalog on 2026-09-10.

Read separately, CVE-2026-67277 is an authentication failure and CVE-2026-86060 is an input-handling failure. Read together, they describe a path from an unauthenticated network position to full administrative control of a device that sits on the network boundary.

Why chains matter more than their parts

Triage processes tend to rank CVEs by individual severity and disposition each one. That approach has a blind spot: it does not ask what a pair of findings can do together. A missing authentication check might be rated serious on its own, and an argument-delimiter flaw might be rated lower, but if the first grants access and the second escalates it, the combined risk is not the sum of two scores. It is a complete compromise.

The MikroTrick chain illustrates the pattern. The authentication flaw removes the gate. The delimiter flaw provides the means to turn the resulting foothold into administrator-level control. Neither half needs to be exotic for the combination to be dangerous.

Exploitation conditions

The chain requires network reach to the RouterOS SSH service on a vulnerable build. That is the whole precondition. The attacker does not need credentials, does not need to guess a password, and does not need to steal a key. CERT Polska's guidance reflects the stakes: any MikroTik device with SSH exposed to the internet should be treated as compromised until it has been checked.

Impact

Administrative control of a RouterOS device means control of routing, DNS, firewall policy, and the traffic passing through. An attacker can create privileged accounts, alter configuration, install scheduled scripts, and use the device as a relay into the internal network. Because the device is always on and seldom inspected, the intrusion can persist without obvious symptoms.

Affected products and scope

The vulnerable builds are RouterOS 6.x before 6.49.21, RouterOS 7.x before 7.23.4, and RouterOS 7.24 before 7.24.2. RouterOS runs on MikroTik RouterBOARD hardware and the Cloud Hosted Router virtual image, and it is widely used in small and mid-sized networks, ISPs, branch offices, and wireless deployments. Reachability remains the deciding factor: a device that never exposes SSH to the internet is not directly reachable through this path.

Exposure context

ZoomEye's app="RouterOS" query returned 2,854,024 matching assets on 2026-09-16, describing the fingerprint-matched population rather than a count of confirmed-vulnerable devices. The CVE-specific query vul.cve="CVE-2026-67277" returned zero indexed assets at the same time, which is typical for a fresh disclosure.

Remediation and mitigations

Upgrade to RouterOS 6.49.21, 7.23.4, or 7.24.2, matching your branch. Then check for signs of exploitation, because the chain was active before the advisory: SSH log entries for the username -2, an unexpected privileged account named ops, unfamiliar scheduled scripts, and connections to the reported addresses 82.192.72.4 and 103.102.31.18. Recent RouterOS builds include a startup integrity check that flags known tampering.

Where compromise is confirmed, rebuild the device rather than editing the live configuration, and rotate any credentials or keys it could have exposed. Going forward, the structural control that matters most is not exposing SSH management to the internet, or restricting it to trusted sources if remote administration is required.