CERT Polska says a two-bug chain it calls MikroTrick is being used to take over RouterOS devices with SSH exposed, with successful attacks traced back to at least September 2 — the day before MikroTik shipped the fix.
What happened
On September 3, 2026, MikroTik posted a short security notice announcing RouterOS 7.25beta3, 7.24.2, 7.23.4, and 6.49.21. The notice named no CVE, described no vulnerability, and said plainly why: “To give time to update your systems, we are not currently publishing detailed information.” It characterized the release as an important security update, said that “most configurations are not at risk,” and told home users that “for regular home device users the issue does not pose an immediate risk.” It added that devices might be marked as flagged after updating, and advised administrators to inspect their configurations for unknown scripts, users, or settings they did not recognize.
The withholding lasted about a day. On September 4, security researcher Nick Pratley published a binary diff of RouterOS 7.23.3 against 7.23.4, along with the same comparison across the 7.24 and 6.49 branches, and reconstructed three of the fixes: a change to parseHashFromDerEncoded that now validates digest length and rejects trailing bytes, a new validLoginParamInput check that rejects usernames beginning with a dash or a space, and a capacity check on a pathname copy in mtget that previously ran an unbounded rep movsb into a fixed-size stack buffer. Pratley published working Python proof-of-concept code for all three, including a script that forges an SSH authentication signature against a low-exponent RSA key.
On September 5, CERT Polska published two advisories and the records reached NVD at 8:17 p.m. UTC. Six CVEs, all with [email protected] as the assigning CNA and all still carrying vulnStatus of Received:
- CVE-2026-67276 — CVSS 4.0 base 9.2, CWE-347. RouterOS compares only the key type and modulus when matching an SSH public key to an authorized user, omitting the exponent. An attacker who knows an authorized RSA modulus can present a key with exponent one, forge a signature, and authenticate as that user without the private key.
- CVE-2026-86060 — CVSS 4.0 base 9.2, CWE-88. An argument-handling flaw in the SSH login path involving usernames that begin with a prohibited character, allowing the trusted RouterOS policy mask to be changed.
- CVE-2026-67277 — 8.8. RouterOS accepts a “related” bandwidth-test connection before the primary session has authenticated.
- CVE-2026-67281 — 8.7. Unauthenticated file read in the WebFig
/jsproxypath, where a new session retains a stale uninitialized principal pointer used for file authorization. - CVE-2026-67279 — 6.9. SSH enters the connection protocol after a client-requested rekey even though authentication was never attempted.
- CVE-2026-67278 — 6.3. RouterOS accepts malformed RSA/PKCS#1 v1.5 signatures during X.509 validation, letting an attacker who controls or redirects an outbound TLS connection forge a trusted intermediate.
All six list the same affected ranges: RouterOS 6.0.0 to before 6.49.21, 7.0.0 to before 7.23.4, and 7.24 to before 7.24.2.
CERT Polska’s advisory opens by stating that combining two of the six “allows an attacker to take full control of the device without authentication” where the device accepts SSH remotely, and that the team named the chain MikroTrick so it could be referred to. Its second advisory says CERT Polska has confirmation that attackers are using that combination against devices whose SSH service is reachable from public networks. The indicators it publishes are specific: successful attacks, including the creation of a privileged account, came from 82.192.72.4 and have been occurring since at least September 2, 2026, and 103.102.31.18 was used in attempts against the same chain. On the account, CERT Polska writes: “An additional indicator of compromise is the presence of a highly privileged user named ‘ops’.” It also warns that the absence of these traces does not rule out unauthorized activity.
CERT Polska credits the discovery to its own team working with OpenAI’s GPT-5.5-cyber and GPT-5.6-sol models under the OpenAI Government and Trust Agency Collaboration program, with human verification and analysis still required.
Why it matters
MikroTik’s September 3 notice was an embargo the vendor could not enforce. A withheld advisory keeps the words private; it does not keep the patch private, because the patch is what every customer downloads. The binaries went out to the whole install base on September 3, and the symbol diff was published on September 4 with runnable exploit code attached. Whatever the notice bought, it was roughly twenty-four hours, and the cost was paid by the people who read the notice rather than the diff.
The sequencing is what makes this more than a style complaint. Attacks were already landing on September 2 — before the release, not after it. The embargo therefore was not withholding information from an attacker who had none. It was withholding indicators of compromise from administrators who were already being attacked. MikroTik’s page told them to look for “unknown scripts, users, or unrecognized settings” without saying that the account to look for was named ops, or that traffic from a specific address was worth searching logs for. Those details existed on September 3; they reached the public on September 5, from a national CERT rather than from the vendor.
The two severity characterizations sit awkwardly together and both are defensible on their own terms. “Most configurations are not at risk” is a statement about the population of deployed devices; MikroTik’s install base is enormous and heavily weighted toward home and small-office units that do not expose SSH to the internet. “Take full control of the device without authentication” is a statement about capability against the ones that do. An administrator running a border router with management SSH reachable needed the second sentence on September 3 and got the first. Neither party has published a count of exposed or compromised devices, so how large the intersection is remains unknown.
The discovery credit deserves attention on its own. A national CERT found six flaws in a router operating system that has been picked over by researchers for a decade, using frontier models supplied under a government access program, and the interval between the vendor’s silent fix and public working exploits was one day. That is the same compression CISA cited as its stated rationale for BOD 26-04 in June — AI narrowing the window between disclosure and exploitation — showing up on the finding side and the weaponization side of the same week. RouterOS is not typical federal civilian equipment and no federal deadline attaches here, but the timing pattern is the one the directive was written around.
One detail is easy to lose in a story about SSH. CVE-2026-67278 is not an SSH bug. Per Pratley’s analysis the same corrected signature-parsing routine sits under X.509 certificate validation, which the router uses on outbound TLS and IKEv2 connections. A device that will accept a forged intermediate is exposed regardless of whether anything inbound reaches it. Closing the SSH port is a good mitigation for the takeover chain and does nothing for that one.
What to do
Upgrade to 6.49.21 on the long-term branch, 7.23.4 on long-term, 7.24.2 on stable, or 7.25beta3. There is no partial fix; these releases carry all six.
Restricting SSH to a management network mitigates MikroTrick and buys time, but treat it as an interim step, not a substitute. It does not address CVE-2026-67278, which lives in outbound certificate validation, and it does not address CVE-2026-67281, which is reachable through WebFig rather than SSH.
Look for a highly privileged user named ops and any other account you did not create. Search logs and firewall records for 82.192.72.4 and 103.102.31.18. CERT Polska’s own caution applies: finding nothing is not clearance. After upgrading, check whether the device carries the flagged marker MikroTik describes, and review the running configuration for scripts, scheduler entries, and users you cannot account for.
If you find evidence of compromise, isolate the device and preserve its logs before touching anything else, then factory reset and restore from a configuration you trust rather than from a backup taken off the device after September 2.
Sourcing note
Checked against primary sources: CERT Polska’s two advisories of September 5, 2026, MikroTik’s own support security page of September 3, 2026, the NVD records for all six CVEs, and Nick Pratley’s September 4, 2026 reverse-engineering writeup. Version ranges, CVSS 4.0 vectors, CWE assignments, and the assigning CNA are taken from NVD, not from coverage.
Could not reach: the cve.org record pages, which require JavaScript and return no data to automated retrieval. CISA’s site was not fetched directly; the KEV check here is the NVD record itself, which republishes CISA’s own cisaExploitAdd and cisaActionDue fields. As of this writing neither field is present on CVE-2026-67276 or CVE-2026-86060, so there is no federal deadline attached. NVD lags the KEV catalog by hours, so a listing added very recently would not yet appear.
Unresolved: CERT Polska does not say which two of the six vulnerabilities make up MikroTrick. The two rated 9.2 are the obvious candidates, and that is an inference, not something the advisory states. MikroTik’s September 3 page carries no CVE identifiers at all, so the mapping between that release and these records comes from CERT Polska and from the version numbers. Neither MikroTik nor CERT Polska has published a figure for how many devices are exposed or how many are known to be compromised, and this report does not estimate one.