An AI Agent Found the Router Bug Within an Hour. MikroTik's Patch Silence Still Bought Nothing.

On 3 September, MikroTik shipped fixes for six RouterOS vulnerabilities across every supported branch and said almost nothing about them. The advisory confirmed an important security update, noted that most configurations were not at risk, and recommended upgrading. Then it said this: "To give time to update your systems, we are not currently publishing detailed information." The company also pushed a notification to the phones of anyone with the MikroTik app installed, the first time in its history it had done that.

The playbook behind that silence is old and reasonable. Ship the fix, hold the details, and let patch adoption outrun public reverse engineering. It assumes the analysis is expensive and slow.

The window had already closed before it opened

Public attack logs on the MikroTik forum and Reddit date from 2 September, a day before the patches existed. CERT Polska traced its confirmed successful intrusions, including the creation of a fully privileged account, to the IP address 82.192.72.4 and said the activity had been running since at least that date. A second address, 103.102.31.18, appears in attempted exploitation.

So whatever breathing room MikroTik intended to buy on 3 September, the attackers were already inside the perimeter the day before. The vendor's quiet period did not start from a clean position.

It did not last either. CERT Polska's own account of the disclosure records that "a public article analyzing these differences appeared on 4 September at 03:22 UTC," the day after the patches, and that its author "described the work as AI-assisted and verified in a laboratory." That first teardown did not reconstruct the full chain, but it named the changed SSH server code and pointed at where to look next. By 5 September the username -2 had been publicly linked to a file descriptor in the RouterOS login program. CERT Polska published the CVE records at 20:00:55 UTC on 5 September, ahead of its own schedule, on the explicit reasoning that keeping the details inside coordinated disclosure channels was no longer stopping anyone from reconstructing the exploit.

Two failures, and one log line that should not exist

The chain CERT Polska named MikroTrick is CVE-2026-67279 and CVE-2026-86060, chained. Together they produced full access to the administrative console without a password, an SSH key, or a completed authentication.

CVE-2026-67279 is the quieter of the two at CVSS 6.9, and on its own it only gets an attacker into the room. SSH runs in layers: establish the encrypted transport, authenticate the user, then handle channels and commands. RouterOS handled a rekey, a routine mid-session renegotiation of encryption keys, incorrectly if the rekey happened during authentication. When it finished, the server moved from the temporary rekey state straight into channel handling, having never sent the SSH_MSG_USERAUTH_SUCCESS message that tells a client authentication passed. No identity, no privileges, but an unauthenticated session channel it should never have reached.

Bishop Fox reproduced the full administrative takeover on vulnerable RouterOS 7.x builds. Its researcher Emilio Gallegos framed the pair as failures at two separate trust boundaries. "The first allows an unauthenticated connection to reach functionality that RouterOS should expose only after login," he wrote. "The second causes the login process to treat data from that connection as a trusted administrative identity."

That second one is CVE-2026-86060, which CERT Polska rates 9.2. RouterOS sends the username in SSH_MSG_USERAUTH_REQUEST before authentication is complete, stores it, and then passes it, unvalidated, into the argument list of a helper program at /nova/bin/login. The helper contains a legacy feature: an argument beginning with a dash is not a username, it is an instruction to read a trusted identity record from a numbered file descriptor. Send -2 as the username and you are telling the helper to read that record from descriptor 2, which is the pseudoterminal attached to your own SSH channel. You supply the identity and the privilege mask yourself. CERT Polska's diagram of the mechanism shows the mask value 655358, the fully privileged group.

The fix is a short validation routine. Patched builds check the username for empty strings, leading dashes or spaces, trailing spaces, and control characters, and reject the rest.

What actually gave the bug away was not the code but the logs. Administrators had been posting two lines over and over: login failure for user -2 from 82.192.72.4 via ssh, followed by user ops added by ssh:[email protected]. A failed login that results in a new administrator account is not a sequence that should exist. CERT Polska combined those public reports with its patch diff and, by its own account, identified the vulnerability, assigned it a CVE number, and handed MikroTik a working proof of concept within an hour.

There is a smaller detail in the same post that says a lot. Administrators also noticed a diagnostic .rif file being created and then transferred to 82.192.72.4 with the fetch command, in more than one published log. That pattern looks like configuration and diagnostic data leaving the device. And the patched firmware added a startup check aimed specifically at an ops account sitting in the privileged full group, disabling it and raising a warning. A vendor does not write an indicator of compromise that narrow unless it already knew the shape of the thing it was looking for.

The other side of the same capability

The research that found the chain was run by an agent. CERT Polska credits Sławomir Rozbicki, who worked with GPT-5.5-cyber and GPT-5.6-sol models under the team's access to OpenAI's Government and Trust Agency Collaboration programme, plus locally hosted open-weight models.

The lab those agents drove, through libvirt, ended up holding 40 RouterOS CHR virtual machines, 39 snapshots, and 24 firmware releases spanning 6.43.11 to 7.25beta3. They ran static analysis over binaries pulled from the RouterOS filesystem with radare2 and Ghidra, and cross-checked behaviour against the relevant SSH RFCs. The approach that paid off was treating the protocol as a state machine and testing what happens when stages are repeated, skipped, reordered, or when a dependent channel opens early. The rekey before authentication completed was one of those tests.

CERT Polska is careful to say this was not a single prompt. Every hypothesis had to be reproduced on a real RouterOS system, with negative control tests, repeats on clean machines, and a human assessment of impact. The team names the expensive parts plainly: preparing usable context about RouterOS, designing a lab that would not produce misleading results, choosing which direction to dig, and then eliminating false conclusions. The models made analysis faster. They did not replace the verification.

The asymmetry, stated better by the researchers than by anyone covering them

Here is CERT Polska's conclusion, and it is the line that matters more than any CVE number in this story: "The speed of LLM-assisted patch analysis is blurring the line between releasing an update and publishing the technical details of a vulnerability." Immediately after it comes the other half: "The lower cost of code analysis did not, however, reduce the time required to test and deploy updates or to examine systems for evidence of prior compromise."

That is the actual situation. Reverse engineering a patch became cheap and fast. Deployment and forensic triage did not move at all. A vendor's decision to withhold detail now buys something much smaller than it did three years ago, and it buys it while an unknown number of devices sit compromised and unexamined. CERT Polska's own remedy is not to delay patches, but to accept that analysis begins the day the package ships and to publish detection guidance and indicators alongside the update rather than after it.

The vendor's compromise detector has the same problem in miniature. Patched RouterOS scans its configuration at startup for known tampering and flags the device if it finds it. It was built to catch the artefacts of this specific campaign, and CERT Polska states the limitation outright: the absence of the marker is not proof that the device is safe. Gallegos put the underlying design point more sharply than a scanner ever could. "MikroTrick exposes a design risk in privileged software: a feature intended only for trusted local callers becomes a remote attack surface when an upstream component loses track of authentication state."

What the exposure numbers do and do not say

The Shadowserver Foundation added MikroTik SSH identification to its daily scans on 4 September and counted at least 122,500 MikroTik devices with SSH accessible in a single 24-hour window on 5 September. That is a measurement of reachable management interfaces, with no vulnerability check attached. Bitsight's continuous internet scanning records 1,818,663 RouterOS observations worldwide.

Neither figure tells you how many devices ran a vulnerable build, how many had SSH reachable from untrusted networks, or how many were actually compromised. No authoritative count of compromised devices has been published by anyone, and CISA's KEV entries record ransomware use as unknown and name no threat actor.

There is also a naming trap worth knowing about, because it has already caught serious organisations. CERT Polska used its 22 September analysis to correct a widespread misreading: CVE-2026-67276, an SSH key validation flaw where RouterOS compares only the type and modulus of an RSA key and skips the exponent, is not part of the MikroTrick chain. It is a separate bug, exploitation requires knowing the account name and the modulus of that account's public key, and it grants only that account's privileges, which makes it a poor fit for a mass attack. The Cloud Security Alliance's 7 September research note had presented 67276 as the first stage of the chain, and the Rescana advisory published the same week as CERT's correction documented both framings side by side and declined to reconcile them. If you have read one article about MikroTrick, it is worth checking which of the two the chain was built from in that telling.

The deadline is the practical part. CISA added CVE-2026-86060 to the KEV catalog on 10 September with a 13 September date for federal agencies, and added CVE-2026-67279 on 25 September with a deadline of 28 September, which is tomorrow. The same Friday action added a Microsoft SharePoint code injection flaw, CVE-2026-65660 at CVSS 8.8, also due 28 September; Microsoft says it "had reliable evidence of observed attacks" as of 25 September and has not said who was behind them, when they started, or how many organisations were hit.

The fixed versions are RouterOS 6.49.21, 7.23.4, 7.24.2 and 7.25beta3. Patching closes the door. It does not remove anyone who came through it, and the only control that works regardless of firmware version is the one MikroTik has recommended from the start: keep SSH off untrusted networks and reach the management plane over a VPN.

Which is a design decision, not an operational one. Whether a device's admin interface is reachable from the open internet is settled when the product is specified, long before an operator unboxes it, and it follows that hardware through every firmware cycle for the rest of its service life. Managing that across a fleet you ship rather than a fleet you own is a different discipline from patching laptops, and it usually surfaces late, after a critical update lands and nobody can reach the field. At DMC we work with hardware and networking companies on exactly that class of problem: management-plane architecture, firmware update paths, and the sourcing and lifecycle decisions behind edge gear that is expected to sit unmanaged in someone else's network. If you are designing for devices you will never physically touch, let's talk.