MikroTik withheld the details for a day. The patch had already published them

A day is not very long

MikroTik released patches for four RouterOS branches on 3 September 2026 and deliberately held back the details. The company described the release as an important security update and, in CERT Polska's words, temporarily withheld the vulnerability details to give administrators time to update their devices. It pushed notifications through its own mobile app to press the point.

A public analysis of what had changed inside those packages appeared at 03:22 UTC on 4 September, on npratley.net. Its author described the work as AI-assisted and verified in a laboratory. MikroTik has not stated the hour at which it published the release, so the outside bound on that gap is 27 hours and 22 minutes, and the real figure is smaller.

By 5 September the decisive trick, a username of -2 being read as a file descriptor, had been publicly connected to the login program. Independent researchers reported reproducing unauthenticated SSH access. CERT Polska then published its CVE records at 20:00:55 UTC that evening, and said plainly why.

keeping the details confined to CVD channels no longer presented a meaningful obstacle to those reconstructing the exploit, but it did restrict the information available to administrators

That sentence is the story. Not the bug.

Say straight away what the arithmetic does not establish.

It does not establish that MikroTik was wrong to ship first and explain later. Shipping a fix quickly is the right instinct and the alternative, holding the patch until the write-up is ready, is worse. CERT Polska is explicit that this asymmetry does not justify delaying patches.

It does not establish that the researchers who reconstructed the chain behaved badly. They published analysis, not a working exploit, and CERT Polska treats their work as a normal consequence of shipping a binary diff to the internet.

It does not establish how many devices were taken over. Nobody has published a count, and the evidence in the public record is a handful of forum and Reddit posts plus reports sent privately to CERT Polska.

And it does not establish that withholding details is pointless in general. It establishes something narrower and more useful: on this occasion, the people the withholding actually slowed down were the administrators.

What MikroTrick actually is

CERT Polska found six vulnerabilities in RouterOS, running from CVE-2026-67276 to CVE-2026-67279 plus CVE-2026-67281 and CVE-2026-86060. Two of them chain, and that chain is MikroTrick.

CVE-2026-67279 is a state machine fault in the SSH server. SSH runs in three layers in a fixed order: transport, user authentication, then connection and channel handling. Either side may start a rekey, which replaces the transport keys without tearing down the TCP connection, and the protocol permits a rekey before authentication has finished. Vulnerable RouterOS builds handled that case wrongly. When the rekey completed, the server moved straight to channel handling rather than resuming the interrupted authentication. It accepted a session channel without ever having sent SSH_MSG_USERAUTH_SUCCESS.

On its own that buys an attacker very little. CERT Polska is careful about this: the flaw established no identity and assigned no privileges. It only moved the connection into a state it had not earned.

CVE-2026-86060 is what makes the state worth reaching. When a client opens a shell, RouterOS starts a child process with a command line of this shape.

/nova/bin/login -ssh -trace <trace> -h <client address> [-c <command>] <username> <policy mask>

The login program does not repeat any credential check. It trusts its parent and builds the console from those arguments. The username, however, arrives in SSH_MSG_USERAUTH_REQUEST before authentication has completed, and the SSH daemon passed it into that argument array without validating it.

A username beginning with a hyphen is therefore read as an option rather than a name. The login program recognises a -N form in which the integer identifies a file descriptor to read a record from. A username of -2 sends it to descriptor 2. Descriptors 0, 1 and 2 all point at the pseudoterminal the attacker is already talking to, so the attacker supplies the record themselves: a name, then a policy mask. The mask 655358 is the one belonging to the full group.

Put the two together and an unauthenticated client reaches a fully privileged RouterOS console without a password, without a key, and without ever completing authentication. The patch closes it by rejecting usernames that begin with a hyphen or a space.

On the record, and not

The gap between what a vendor says at patch time and what an administrator needs is easiest to see side by side.

What was available to an administrator on 3 September, against what was established later. Drawn from CERT Polska's technical analysis and the CISA KEV catalogue.

Question an administrator had on 3 September	Stated at the time	Established later
Is this being exploited now?	Not stated. The release was described as an important security update	Public attack logs dated from 2 September, the day before the patch
What does the attack look like in my logs?	Not stated	A failed login for user -2, then an ops account created in the same session
Does SSH key authentication protect me?	Not stated	No. An account was created on devices configured for keys only and strong crypto
Which flaws are in the chain?	Not stated	CVE-2026-67279 with CVE-2026-86060. CVE-2026-67276 was wrongly linked to it in some coverage
How urgent is this really?	Upgrade as soon as possible, by app notification	Added to the CISA KEV catalogue on 10 September with a three day deadline

Be fair to MikroTik on one point. CERT Polska had intended to synchronise its publication with the updates and says the new versions arrived sooner than expected. Part of this gap is an ordinary coordination mismatch between a vendor moving fast and a reporter preparing a write-up, not a decision to keep administrators in the dark.

But the vacuum had an effect that nobody chose. CERT Polska records that the urgency of the announcement, combined with the absence of specifics, prompted extensive speculation on MikroTik's own forum, and that users began posting device logs there suggesting attacks had started before the patches. The logs that eventually identified the second vulnerability were posted by administrators trying to work out what had happened to them.

The indicator that shipped inside the patch

This is the detail worth carrying into your next vendor conversation.

When CERT Polska diffed the patched packages, it found more than the username validation. The update also changed the Flagged mechanism, which marks configuration entries that may indicate compromise. A new rule ran at startup and looked for an ops account belonging to the privileged full group. If it found one, RouterOS disabled the account, logged a warning, and set the Flagged status.

That is not a hardening measure. It is a signature for one specific attacker's post-exploitation artefact. CERT Polska draws the obvious inference and states it as an inference rather than a fact: the introduction of such specific indicators could mean the vendor had at least partial knowledge of the attacks.

So the patch shipped an indicator of compromise, silently, inside a binary, to a fleet of administrators who were told only that the update was important. Any one of them who ran the fixed build and saw a disabled ops account in a warning log had been handed evidence of a breach without being told that is what it was.

Keys and strong crypto were not the control

Public key authentication is the advice everybody gives for exposed SSH, and it is good advice. It was not a control against this.

CERT Polska reports that one administrator confirmed an administrative account had been created successfully on devices configured to use only SSH keys and strong crypto. The reason follows from the chain. CVE-2026-67279 does not defeat authentication, it steps around the point at which authentication would have been checked. A policy that governs which authentication methods are acceptable never runs, because the server never gets as far as deciding whether the client authenticated.

This is the friendly-name fallacy in its purest form. "Key only authentication" describes a setting. The control it is supposed to represent is "nobody reaches a privileged console without proving who they are". When the state machine skips the proof, the setting is still correct and the control has not existed for the whole session.

The same logic applies to the strong crypto option, and to anything else configured inside the authentication layer. The only settings that mattered here were the ones outside it: whether the SSH service was reachable from the internet at all, and from where.

login failure for user -2 from 82.192.72.4 via ssh
user ops added by ssh:-2@82.192.72.4

Those two lines are the whole detection, and they are worth understanding rather than copying. The first says authentication failed. The second says an account was created by the session that failed. Nothing legitimate produces that pair. You do not need the username -2 or the address 82.192.72.4 to search for it, and you should not rely on either, because both are one attacker's choices on one set of devices. What generalises is the shape: a privileged change attributed to a session whose authentication is recorded as having failed.

The reconstruction clock

Lay the dates out and the shape of the modern disclosure problem is visible without any argument about who was right.

Attacks were already running on 2 September. The patch landed on 3 September with no details. A public analysis of the SSH changes was online by 03:22 UTC on 4 September. By 5 September the file descriptor trick was public and independent researchers were reporting successful reproduction. CERT Polska published its CVE records at 20:00:55 UTC on 5 September. CISA added CVE-2026-67277 and CVE-2026-86060 to the Known Exploited Vulnerabilities catalogue on 10 September with a three day remediation deadline, which fell on 13 September.

That is eight days from the first public evidence of exploitation to the catalogue entry that tells a federal agency to treat it as an emergency. For most of those eight days the people who most needed the technical detail had the least of it.

Both sides brought an agent

CERT Polska is unusually open about its method, and the openness is the point rather than the novelty.

The RouterOS research ran on GPT-5.5-cyber and GPT-5.6-sol with reduced refusal thresholds, obtained through OpenAI's GTAC programme, alongside locally hosted open weight models including GLM, DeepSeek, Qwen and the Polish PLLuM. The agent drove libvirt to build virtual machines, take and restore snapshots, run tests and collect artefacts. By the end the laboratory held 40 CHR virtual machines, 39 snapshots and 24 RouterOS releases spanning 6.43.11 to 7.25beta3.

What the models were good at is specific and worth repeating, because it tells you where this technique will be used next. CERT Polska found them particularly effective at analysing protocols as state machines: systematically testing what happens when stages are repeated, messages are skipped or reordered, or dependent channels are opened early. A rekey before authentication completed was exactly that kind of test, and it is what surfaced CVE-2026-67279.

The honest part of the account is the cost. The most time-consuming work was preparing the context and the laboratory, resolving ambiguous results, and validating findings against real releases. A vulnerability was treated as confirmed only after repeatable results, negative tests, artefact analysis and comparison across several versions. The agent removed manual labour. It did not remove the burden of proof.

And the same capability sat on the other side of the fence. The first public patch analysis, at 03:22 UTC the morning after the release, was described by its own author as AI-assisted. CERT Polska's conclusion is the sentence every vendor should read before the next quiet update.

There is a practical consequence for anyone who buys network equipment. A quiet patch is no longer quiet. The binary is the disclosure, it is readable within hours, and the only question a vendor now controls is whether the accompanying advisory is better or worse than what a stranger will reconstruct from the diff by breakfast.

On this occasion the stranger was faster and more specific than the vendor, and the difference was paid for by people running routers.

What to do, in order

The closing question is not about MikroTik, which shipped a fix quickly and pushed people to install it.

It is this. Your vendors are about to publish patches whose details will be public within a day whether they participate or not. When that happens, the only variable left is whether your administrators learn what to look for from the vendor, or from a forum thread written by somebody who has already been breached.

Which of your suppliers could you name, today, that would tell you?

Key facts