A national CERT found six RouterOS flaws with a cyber model, and wrote down exactly what the model did not do

CERT Polska published six RouterOS vulnerabilities on Friday. Two of them chain into unauthenticated takeover of any MikroTik device with SSH exposed to the internet, and they are being exploited now.

Their words, not a summary: "We have obtained confirmation that the attackers are exploiting this combination of vulnerabilities to take full control of devices whose SSH service is accessible from public networks."

That alone is the operational story and I will get to it. But the last section of the post is the more interesting one, and almost nobody has quoted it.

The vulnerabilities were found using AI models, and CERT Polska have set out exactly what the models did and did not do.

The division of labour

What the agent did, and what the researchers did

Verbatim: "The vulnerabilities were discovered by the CERT Polska team using the GPT-5.5-cyber and GPT-5.6-sol models as part of the team's access to the OpenAI Government and Trust Agency Collaboration (GTAC) program."

So this is the Daybreak Red model, the one we covered in August when OpenAI published its refusal figures, in the hands of a national CERT, producing six real flaws in a widely deployed router platform, two of which are in active exploitation within days.

The technique they single out is worth writing down because it generalises: "Modeling protocols as state machines and checking what happens when a stage is skipped, repeated, or executed in the wrong order proved particularly effective."

And then the paragraph that makes this worth a briefing rather than a headline:

"This was not, however, the result of a single instruction (prompt). Every hypothesis required confirmation on a real RouterOS system, negative control tests, repetition on a machine in a clean state, and an impact assessment by the researchers. Despite the high degree of automation, the most labor-intensive parts of the project were preparing useful context about RouterOS, designing a safe laboratory and tools, choosing research directions, and then fully verifying the results, eliminating false conclusions, and documenting the real impact."

This is the first case I have seen where an AI-assisted discovery claim arrives with its own honest denominator. Compare it with the Cisco IOS XR advisory a week ago, which said the flaws were found "using existing testing processes as well as frontier AI models" and left it there, and with the vendor claims that pair a model with a solve rate and no account of the scaffolding.

What is actually broken

Now the part that matters this morning if you run any of these.

CVE-2026-67276, CVSS 9.2. RouterOS "did not properly verify public keys used for SSH authentication", failing to compare the entire RSA public key. An attacker who knows the username and the public modulus can craft a different key and log in without the private key.

CVE-2026-86060, CVSS 9.2. RouterOS mishandled usernames beginning with a disallowed character, so a crafted username elevates the session to "full administrative privileges".

Chain those two and you have unauthenticated administrative access. CERT Polska named the chain MikroTrick.

CVE-2026-67277, CVSS 8.8, is separate: the bandwidth-test service lets an unauthenticated connection reach a state that should require login, and combined with uninitialised buffer data and an integer underflow yields kernel memory disclosure or a remote restart.

Fixed in 7.25beta3, 7.24.2, 7.23.4 and 6.49.21. MikroTik also, for the first time in its history, sent a push notification to users with its app installed.

Indicators, and what each one does and does not prove

Indicator	What it means	The qualification they attach
A highly privileged user named “ops”	The account created by the observed attacks	Its absence does not rule out unauthorised activity
Log line: login failure for user -2 from <ip> via ssh	An attempt against the crafted-username flaw	As above. Investigate any occurrence immediately
Log line: user <name> added by ssh:-2@<ip>	A successful account creation via the chain	As above
Source IP 82.192.72.4	Successful attacks including the “ops” account, occurring since at least 2 September	A single observed source. Not the whole population
Source IP 103.102.31.18	Used in attempts to exploit the chain	As above
The “Flagged” marker in /system/device-mode/print	MikroTik scans at startup for known signs of unauthorised change and flags them	“This mechanism detects only selected traces left after a compromise. The absence of the marker is not proof that the device is safe”

That last row is the one to read twice. The vendor shipped a detection mechanism with the fix, and the CERT went out of its way to say what it does not cover, adding that the marker "should therefore be treated as an indication of a possible earlier compromise, not as proof that one of the vulnerabilities reported by CERT Polska was exploited".

The position

Two things happened here and they are usually reported as one.

A frontier cyber model, accessed through a government programme, materially accelerated vulnerability discovery at a national CERT. That is a real capability result, arriving in the same fortnight as Cisco attributing an IOS XR hardening release partly to frontier models and OpenAI declaring a model Critical for cyber capability. The direction of travel is no longer arguable.

And a team that could have claimed the whole thing for the machine wrote down, unprompted, that the machine did the automatable part and the people did the part that determines whether any of it is true. Preparing context. Designing the lab. Choosing what to look at. Killing false positives. Establishing real impact.

Both halves are the story. Anyone quoting the first without the second is describing a different project from the one CERT Polska ran.