A Patch Is Not a Recovery: The MikroTik MikroTrick Lesson for Every Connected Device

What this is. Opinion + Experience + Fact (45% opinion · 20% experience · 35% fact). Written in collaboration with AI — I discuss, I do not outsource.

A field note on the MikroTik RouterOS fixes of September 3, 2026 and the "MikroTrick" exploit chain that was already in use a day earlier. The short version: the patch closes the way in, and the patched firmware now checks itself for tampering at startup — but a patch removes the way in, not what already got in. Recovery is a design feature, and this incident is a clean lesson in how to ship it.

On September 3, 2026, MikroTik published fixed RouterOS builds in every release channel — 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 — and deliberately withheld the technical details so people had time to update. Two days later, CERT Polska published its advisory: six vulnerabilities, two of them critical, and a name for the chain that combines them, "MikroTrick." It also confirmed the part that matters most: the chain was already being used to take full control of routers whose SSH (remote-login) service was reachable from the internet, with attacks observed from at least September 2 — a day before the fix shipped.

I read a lot of security advisories, and most of them end at "update now." This one is worth studying past that line, because of what the fixed firmware does after it installs, and what the advisory is honest enough to admit it cannot do. If you ship connected devices, that second half is your lesson.

---

1. The fix closes the door. It does not check the house.

The chain pairs two bugs. The first, CVE-2026-67276, is an SSH authentication bypass: RouterOS did not compare the entire RSA public key assigned to a user, so an attacker who knew a username and the public modulus of that user's key could craft a different key and log in without the private key. The second, CVE-2026-86060, lets a crafted username manipulate the SSH session into full administrative rights. Together they turn "SSH open to the internet" into "someone else's router."

The fixed builds close both doors, and CERT Polska confirmed the patches stop the attacks it observed. But read the advisory's recommendation list and you'll notice the second half of it is about something else entirely: after updating, check for unknown users, scripts, scheduler tasks, proxy servers and tunnels. The attackers it watched were creating a highly privileged user named "ops." A patch does nothing about that user. Every device taken over in the window before September 3 still needs a cleanup after it updates.

▸ First principle. A patch removes the way in; it does not remove what already got in.

2. What does the "Flagged" mechanism do?

Here is the part I found most interesting. The fixed releases add a mechanism that runs at startup: it scans the device's configuration for known signs of unauthorized changes, disables the suspicious entries it recognizes, writes a critical message to the log, and sets a warning marker — "Flagged" — that an administrator can read with /system/device-mode/print. In plain words: the device checks itself for tampering and raises a hand if it finds any. MikroTik also, for the first time, pushed a phone notification to users of its mobile app to tell them to update.

The advisory is equally clear about the limits, and I think that honesty is the most useful part of it. The mechanism detects only the traces it was taught. The absence of the marker is not proof the device is safe. And a raised marker means "assume the device was taken over," not "we know exactly which bug was used." So the instruction for a flagged device is the full recovery: isolate it, preserve the logs and configuration, factory reset, rebuild from a trusted and verified configuration, and rotate every password, key and secret. Do not blindly restore a full backup taken from a device you no longer trust.

Still — a device that can say "I may have been changed" is a big step up from one that quietly keeps running in the field as if nothing happened. That is the design idea worth stealing.

▸ First principle. A device should be able to report its own tampering, and that report has to reach someone.

3. How should firmware be designed so recovery is possible?

Three things I take from this, for any connected product, not just routers.

Keep a known-good baseline you can diff against. A self-check can only recognize tampering if it knows what "untouched" looks like. That means a signed, versioned baseline of the configuration and the firmware identity, stored where an attacker with a shell cannot quietly edit it, and a rebuild path from that baseline rather than from the last backup.

Make integrity and identity part of normal telemetry. A critical log line on the device is only useful if someone reads it. On a fleet, nobody reads device logs one at a time. The firmware-and-configuration stamp, the boot count, the "I disabled something at startup" event — those belong in the same stream as battery and signal strength, so a flagged device shows up on a dashboard instead of in a forensic export months later.

Model the protocol as a state machine, and test the wrong orders. CERT Polska credits its LLM-assisted research setup with finding these bugs, and names the technique that worked best: modeling the protocols as state machines and checking what happens when a stage is skipped, repeated, or executed in the wrong order. Explicit state tables make that question answerable, for the attacker and for you. It's the same reason EmbedIQ, the open framework I work on, gives each task a table-based state machine and one message queue — you can read the table and ask "what if this arrives twice?" before someone else does.

And there's a date attached. From September 11, 2026, the EU Cyber Resilience Act requires manufacturers of products with digital elements to report an actively exploited vulnerability within 24 hours of becoming aware of it, with a fuller notification at 72 hours and a final report within 14 days. An incident like MikroTrick is exactly that class of event. Detecting compromise in your own product is about to be a legal deadline, not just good hygiene.

▸ First principle. Recovery is a design feature; you ship it in the firmware or you improvise it in the field.

The copyable part: a post-patch recovery checklist for any device

Step	What it answers	RouterOS example (Sept 2026)
1. Patch	Is the way in closed?	Update to 7.24.2 / 7.23.4 / 6.49.21 (or 7.25beta3)
2. Self-check	Does the device see known tampering?	Startup scan disables recognized entries → critical log line + "Flagged" marker
3. Human check	What did the self-check miss?	Unknown users (e.g. "ops"), scripts, scheduler tasks, proxies, tunnels; log lines from user "-2"
4. Preserve	What evidence do we keep?	Secure logs + configuration before any reset
5. Rebuild	Are we starting from a trusted state?	Factory reset, reconfigure from a verified config — not a restored backup
6. Rotate	Are old secrets dead?	Change passwords, keys and other secrets
7. Report	Who needs to know, and by when?	National CSIRT; from Sept 11, 2026 the CRA 24h / 72h / 14d clock for manufacturers

Seven rows. Only the first one is "the patch." The other six are what recovery actually is — and the question to ask about your own product is how many of them your firmware makes easy.

When one of your devices gets patched, how do you know what was already inside it?

Next in this thread: a quiet device is not a healthy one — why silence from the field is a signal, not a comfort.

Sources

Vendor bulletin: MikroTik — September 2026 vulnerability (September 3, 2026: fixed versions, "Flagged" status, upgrade guidance). Coordinated disclosure and exploitation confirmation: CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited (September 5, 2026: CVE-2026-67276, CVE-2026-86060, CVE-2026-67277, the "MikroTrick" name, indicators of compromise, recovery steps, the state-machine research note). Reporting: BleepingComputer — Hackers exploit new MikroTik RouterOS flaws to hijack routers (September 7, 2026; also relays The Shadowserver Foundation's count of roughly 122,500 MikroTik devices with SSH exposed as of September 5 — exposure, not confirmed vulnerability). Regulation: European Commission — Cyber Resilience Act reporting obligations (from September 11, 2026: 24-hour early warning, 72-hour notification, 14-day final report). CVE identifiers and version numbers are quoted from the vendor and CERT sources; everything else in this piece is my reading of them.

FAQ

What is the MikroTik "MikroTrick" vulnerability chain?
MikroTrick is CERT Polska's name for a combination of two RouterOS bugs: CVE-2026-67276, an SSH authentication bypass caused by comparing only part of a user's RSA public key, and CVE-2026-86060, a privilege escalation via a crafted SSH username. Together they let an attacker take full administrative control of a router whose SSH service is reachable from the internet. Fixes shipped on September 3, 2026 in RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21, and the chain was confirmed to be actively exploited from at least September 2.

What does the RouterOS "Flagged" status mean?
The fixed RouterOS releases add a startup self-check that scans the configuration for known signs of unauthorized changes, disables the suspicious entries it recognizes, writes a critical log message, and sets a "Flagged" marker visible via /system/device-mode/print. A flagged device should be treated as compromised. The absence of the marker is not proof the device is clean, because the check only recognizes traces it was taught.

Why is a patch not the same as a recovery?
A patch removes the vulnerability — the way in. It does not remove anything an attacker already added while the way in was open, such as extra users, scripts, scheduled tasks or tunnels. Recovery means detecting those changes, preserving evidence, rebuilding from a trusted configuration rather than restoring a possibly tainted backup, rotating all secrets, and reporting where required.

How does the EU Cyber Resilience Act apply to an incident like this?
From September 11, 2026, manufacturers of products with digital elements sold in the EU must report an actively exploited vulnerability within 24 hours of becoming aware of it (early warning), follow up within 72 hours, and file a final report within 14 days, through the CRA single reporting platform to ENISA and the relevant national CSIRT. An actively exploited chain like MikroTrick is exactly the class of event those obligations cover.

This is a Ritzy Lab field note. If you ship connected devices and want to compare notes on recovery-by-design, the longer story and how I work live on my profile. — Ritesh | ritzylab.com