BREAKING: CVE-2026-67276 and MikroTrick can take over MikroTik RouterOS with SSH exposed

CERT Polska confirmed active attacks against MikroTik RouterOS that chain SSH flaws into full device takeover when SSH is reachable from the internet. They call that chain MikroTrick. CVE IDs landed today (2026-09-05). MikroTik already pushed silent fixes on 2026-09-03 in 7.24.2, 7.23.4, and 6.49.21. If you run RouterOS with management services on a public address, patch and hunt for compromise markers now. This post covers the six CERT-coordinated CVEs in one upgrade.

This is the operator write-up. The HOL Guard evidence packs for each CVE ID are the source records.

What breaks

MikroTik's Sep 3 bulletin said only that a security update was important and that most configurations were not at risk. The binaries disclosed more than the prose. CERT Polska's Sep 5 write-up, plus independent binary diffs of 7.23.3 vs 7.23.4, map six issues:

• CVE-2026-67276 (CVSS 9.2 per CERT) - SSH public-key auth compared RSA key type and modulus but not the exponent. An attacker who knows an authorized RSA modulus can supply a crafted key (commonly e=1 / low-exponent forgery paths) and open an SSH channel as that user without the private key.
• CVE-2026-86060 (CVSS 9.2 per CERT) - usernames that begin with a prohibited character (field IoC: literal -2) reach a legacy login helper that treats -N as "read trusted name/policy fields from file descriptor N." That can replace the RouterOS policy mask and escalate to full admin. CERT pairs this with 67276 as MikroTrick.
• CVE-2026-67279 - SSH rekey before authentication lets an unauthenticated client open a session and write or overwrite files in the managed file namespace (including support/config material).
• CVE-2026-67281 - WebFig /jsproxy unauthenticated file read via a stale principal pointer and path escape; can disclose config stores that hold credentials.
• CVE-2026-67277 (CVSS 8.8 per CERT) - bandwidth-test (btest) accepts a "related" connection before the primary session finishes auth, leaking kernel buffer data or crashing/restarting the device.
• CVE-2026-67278 - malformed RSA/PKCS#1 v1.5 signatures accepted in X.509 validation; with an e=3 trust-store root this enables TLS server impersonation on outbound RouterOS TLS.

Fixed trains (vendor + CERT): 7.24.2 (stable), 7.23.4 (long-term), 6.49.21 (v6 long-term), and 7.25beta3+. Affected range per CERT: from 7.24 below 7.24.2, from 7.0.0 below 7.23.4, from 6.0.0 below 6.49.21.

CERT reports observing internet-facing SSH devices taken over with this combination in recent days, and that the released patches stop the observed attacks. MikroTik's patched builds also set a Flagged device-mode marker when known compromise fingerprints are present.

Who is not in scope

• Devices already on 7.24.2, 7.23.4, 6.49.21, or any later build that contains these fixes (still run the Flagged / IoC checks below if SSH was ever public).
• Boxes where SSH, WWW/WWW-SSL (WebFig), and the bandwidth-test server are not reachable from untrusted networks, and that do not initiate untrusted outbound TLS/SSH client sessions from the router. MikroTik's own bulletin still says regular home/default layouts are lower immediate risk; that is exposure scoping, not a skip.
• This is not a claim that every RSA key on every RouterOS install is forgeable. The SSH auth bypass needs knowledge of an authorized RSA modulus (and the weak verifier behavior). Independent lab work reproduced public-key auth without the private key against authorized e=3 keys on 7.23.3; stock e=65537 is not a universal break.

Operator check

# version (want 7.24.2+, 7.23.4+, or 6.49.21+)
/system resource print

# Flagged marker after upgrade/reboot
/system device-mode print

# IoCs CERT associates with the in-the-wild chain
/log print where message~"-2"
/user print where name="ops"

# management exposure (tighten if these listen on WAN)
/ip service print
/ip firewall filter print where chain=input

Log lines to treat as compromise attempts (CERT):

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

Also hunt unexpected full-policy accounts, scheduler entries that fetch then import, SOCKS proxies, and tunnels you did not create. Absence of Flagged is not proof of cleanliness. MikroTik documents that the marker only catches selected fingerprints.

If you use RADIUS / User Manager for SSH, review whether a username like -2 could ever be accepted from an external AAA path. Independent reverse-engineering of the silent patch reproduced post-auth policy injection once SSH accepted that username, and could not reproduce a stock local-user password path that accepts literal -2 without that precondition.

How to fix

Upgrade RouterOS immediately to 7.24.2, 7.23.4, 6.49.21, or newer via System → Packages → Check for Updates (or your normal image pipeline). Prefer the channel you already run (stable vs long-term). Do not leave older "still listed as long-term" builds such as unpatched 7.20.x / 7.21.x in place: MikroTik's forum clarification is that the fix starts at the named releases, and many years of versions are affected.

Until you can patch: remove SSH, WWW/WWW-SSL, and bandwidth-test from untrusted addresses; do not use /system ssh / /system ssh-exec or outbound TLS from an unpatched box across untrusted paths. Those are temporary exposure cuts only.

If Flagged, IoCs, or unknown users/scripts appear: isolate the device, preserve logs and config for IR, factory-reset, rebuild from a known-good config, and rotate passwords, keys, and RADIUS secrets. Do not blindly restore a full backup from a possibly compromised unit. CERT also warns against clearing the Flagged marker before evidence is secured.

Extra hardening after patch (from the silent-patch analysis, not required by the CVE text alone): audit authorized SSH RSA keys for exponent 3 and prefer Ed25519/ECDSA or RSA e=65537; remove test policy from accounts that do not need diagnostic tools (built-in read includes test and can reach unsafe helpers); restrict or disable MAC-Telnet on untrusted L2.

What this is not

This is not a claim that every MikroTik on the internet is owned without SSH (or the other listed services) being reachable. It is not a silent worm against firewalled management planes. It is also not "CVE assignment of a years-old dead bug": the vendor patched on Sep 3, CERT published CVE detail and active-exploitation confirmation on Sep 5, and internet-exposed SSH is the live blast radius right now. Guard's knownExploited flag may still read false until KEV/NVD catch up; believe CERT's operational confirmation over that lag.

References

• HOL Guard evidence pack (CVE-2026-67276)
• CERT Polska: actively exploited MikroTrick advisory
• CERT Polska: CVE table and per-ID descriptions
• MikroTik September 2026 vulnerability bulletin
• MikroTik forum: Important security update
• Independent silent-patch reverse engineering (7.23.3 vs 7.23.4)
• Sibling Guard packs: CVE-2026-86060, CVE-2026-67279, CVE-2026-67281, CVE-2026-67277, CVE-2026-67278