MikroTrick: An LLM Found Six RouterOS Flaws That Chain Into a Free Admin Account — Patch Before Sep 13

The short version//

CERT Polska (Poland's national CSIRT) disclosed six RouterOS vulnerabilities on September 5, and they're already being exploited in the wild. Two of them chain into a zero-authentication full device takeover: no credentials, no password spray, no brute force — just an SSH connection to a box that has port 22 open to the internet. The team named the chain MikroTrick, and their writeup confirms attackers are using it right now, on devices with SSH reachable from public networks.

CISA added CVE-2026-86060 and CVE-2026-67277 to the KEV catalog on September 10 (they're the two most recent entries in a catalog of 1,705), with a federal remediation due date of September 13. That's two days from now. The fixes are in RouterOS 7.24.2 (Stable), 7.23.4 (Long-term), 6.49.21 (Long-term), and 7.25beta3, per the MikroTik security bulletin.

And here's the kicker: these six bugs were found by a human researcher with an LLM doing the heavy lifting, under OpenAI's government program. More on that below, because it changes what "vuln hunting" looks like in 2026.

The chain, in plain English//

The takeover needs two flaws working together:

CVE-2026-67276 (CVSS 9.2) — SSH auth bypass. RouterOS matches an incoming SSH public key against the user's authorized keys by checking the key type and modulus only — it never compares the exponent. That sounds like a detail, but RSA keys are (modulus, exponent) pairs, and RouterOS treats "same modulus" as "same key." An attacker who knows the username and an authorized modulus can supply their own key with exponent one (e=1) — a key where forging a valid signature is trivial math — and open an SSH command channel as that user, without ever holding the private key. The privileges obtained are exactly the target account's.

CVE-2026-86060 (CVSS 9.2) — policy mask flip. RouterOS mishandles SSH usernames that begin with a disallowed character in its login path. A crafted username flips the trusted RouterOS policy mask, and the resulting session comes up with full administrative privileges. An unauthenticated client just needs to reach the login helper.

Stack them: forge your way into some user's key (67276), then ride the crafted-username path into full admin (86060). Result: a stranger owns your router, and the only precondition was that SSH is reachable from the internet. Per Shadowserver (quoted in Help Net Security), that precondition covers at least 122,500 MikroTik devices per 24-hour scan window as of Sep 5.

The other four (because six is a lot)//

The CERT Polska CVE page lists all six, with published scores only for the top three:

• CVE-2026-86060 (CVSS 9.2) — SSH argument injection → full admin. On KEV.
• CVE-2026-67276 (CVSS 9.2) — RSA exponent not checked in SSH key auth → auth bypass.
• CVE-2026-67277 (CVSS 8.8) — the bandwidth-test service accepts an unauthenticated "related" connection before the primary session authenticates; combined with uninitialized packet-buffer disclosure and an unsigned integer underflow, it leaks kernel memory or restarts the RouterOS kernel. On KEV.
• CVE-2026-67278 — malformed RSA/PKCS#1 v1.5 signatures accepted during X.509 validation; because the trust store includes an e=3 root CA, a MITM can forge a trusted intermediate and impersonate any TLS server the router connects to.
• CVE-2026-67279 — after a client-requested SSH rekey, RouterOS enters the connection protocol before authentication was ever attempted, letting an unauthenticated client open a session channel and run exec — creating, overwriting, or reconstructing files in the managed file namespace.
• CVE-2026-67281 — WebFig's /jsproxy path dereferences a stale uninitialized principal pointer on newly allocated sessions; an attacker can escape the WebFig file namespace and read root-owned config stores containing credentials.

Note which two made KEV: the privesc and the DoS/memory-leak, not the auth bypass itself. That's fine; it still signals active exploitation of the chain.

The IoCs you can grep today//

CERT Polska published concrete markers from the observed attacks. This is a hunt you can run tonight with nothing but grep and your log files:

1. Grep your RouterOS logs for these exact lines: login failure for user -2 from <ip> via ssh user <name> added by ssh:-2@<ip>
2. Check for a highly privileged user named ops that you don't recognize. Confirmed successful attacks, including the creation of that account, trace back to attacker IP 82.192.72.4, active since at least September 2. A second address, 103.102.31.18, was used in attempts against the same chain.
3. Check /system/device-mode/print for the Flagged marker (next section).

The absence of these traces does not rule out compromise; CERT Polska is explicit about that. But their presence means investigate immediately.

The "Flagged" mechanism: a patch that checks your work//

MikroTik shipped something nice with this one: the patched builds scan the configuration at startup for known signs of unauthorized changes, disable the recognized suspicious entries, write a critical log message, and set the device to Flagged status (details in MikroTik's Flagged documentation). If your log has a critical entry saying your device is Flagged after upgrading:

1. Isolate the device from the network.
2. Secure the logs and configuration before you reset anything, exactly as CERT Polska sequences it, so forensics doesn't die with the factory reset.
3. Restore to factory settings and rebuild from a trusted configuration; do not blindly restore a full config backup taken from a potentially compromised device.
4. Rotate passwords, keys, and secrets that lived on or through that box.

Treat Flagged as "possible earlier compromise," not proof of which bug was used; the scan only catches selected known traces, and MikroTik itself can't rule out additional unfixed bugs.

If you can't patch tonight//

CERT Polska's temporary measures, in order:

1. Block SSH from untrusted networks (the chain's front door), plus WWW/WWW-SSL and the bandwidth-test server, which have their own flaws.
2. Don't initiate TLS connections from an unpatched device over untrusted networks, and don't use its built-in SSH clients (/system ssh, /system ssh-exec): CVE-2026-67278 means your outbound traffic can be impersonated, and the client-side bugs are live.
3. These reduce surface; they do not replace the patch.

The AI angle: a national CSIRT running an LLM lab//

The six bugs were found by Sławomir Rozbicki of CERT Polska using GPT-5.5-cyber and GPT-5.6-sol, under OpenAI's Government and Trust Agency Collaboration (GTAC) program, the same arrangement that puts frontier models in front of government security teams. The setup was an agent-based research environment: an isolated lab full of RouterOS machines, architecture docs, and safe-test rules; the agents automated machine creation/restore, version comparison, RFC analysis, binary analysis, and exploit-script building.

The technique that worked best: modeling protocols as state machines and checking what happens when a stage is skipped, repeated, or run out of order. (Sound familiar? That's exactly how you find "rekey before auth" bugs like CVE-2026-67279.) CERT Polska stresses it wasn't one magic prompt. Every hypothesis needed confirmation on real hardware, negative controls, and human impact assessment. The models accelerated analysis; they didn't replace verification. But the workflow is now a national CSIRT workflow, and other agencies are watching.

What you should do//

1. Upgrade RouterOS to 7.24.2 / 7.23.4 / 6.49.21 (or 7.25beta3 if you live on the edge); verify the version string afterward; RouterOS upgrades are not known for silently no-oping, but check anyway.
2. Run the IoC hunt above: log grep for user -2, unknown ops account, and the two attacker IPs.
3. Check /system/device-mode/print for Flagged status after upgrading; if flagged, follow the isolate-secure-rebuild sequence.
4. Audit your config for unknown users, scripts, scheduler tasks, proxy servers, and tunnels, even when not Flagged.
5. Close SSH to the internet unless you truly need it bare; a WireGuard VPN in front is MikroTik's own recommendation in the bulletin. If you've done our 10-minute router hygiene drill, this step was already on the list.
6. Report to your CSIRT (or CERT Polska, if that's yours) with secured logs and config if anything looks off.

And if you've been following along: last month we covered MikroTik's unpatched API brute-force flaw. That one had no fix; this one has a fix, IoCs, and a self-checking patch. The "MikroTik again" pattern is the real story, but tonight it's a solvable one.