Not mine...
RADIUS is absolutely not required, nor is existence of any prior user account or knowledge of its username. It's absolutely possible to coerce SSH into desired state with a bit of magic - Nick's blog writeup comes close but he never tries to avoid authentication and uses RADIUS instead. As to what this magic is - you're free to point clanker at it and figure yourself. Between here and Nick's writeup you have enough puzzle pieces for even Opus 4.8 to be able to figure this out fairly quickly. It's not rocket science, it's just unusual.
Irrelevant. The vulnerability was being actively exploited by script kiddies en masse before MikroTik even released patches, in fact I'm 100% confident that they only got to know about this from inspecting logs of one such device. God only knows how long this was being used by more skilled attackers that did not leave obvious traces.
Hahaha, please don't make me laugh so hard. Maybe you mean CVE-2026-39042? Go ahead and point me at a changelog entry or security bulletin that MikroTik released for it. I'll save you digging, here it is:
system - improved stability for internal RouterOS service communication;
Or maybe remind me where can I get details about the PPP issue they fixed 2 months ago? They even redacted changelog post-fact to remove that one mention. They deemed it big enough to release patch for v6 specifically, but you'd be hard pressed to find any security bulletin for it on their official page. Things aren't getting better. They're still only open about it if it's critical enough that it's clear people will start reporting their devices being pwned within hours. Anything less than that is free game.
Got hit by the ops/sshd thing on Sep 2, source IP 82.192.72.4 (paramiko + a Go client). Trying to work out if I should treat this as compromised or not, because it looks like the exploit got in but the payload didn't run.
In the system log the only thing from that IP is failed logins for "-2":
Sep/02/2026 02:27:56 system,error,critical login failure for user -2 from 82.192.72.4 via ssh
Sep/02/2026 03:28:45 system,error,critical login failure for user -2 from 82.192.72.4 via ssh
No "user ops added", no ops login, no fetch upload. info logging is on (I see other info entries around then), so a user add would have shown up.
The @sshd part of the autosupout.rif shows the actual bypass though - unauth "-2", a forced rekey, and then it jumps straight to a channel + exec with no password:
auth req: -2 ssh-connection none
next auth methods: publickey,password
rekey
transport state: 4 --> 6
transport state: 6 --> 5
channel #0 opened 0 w:200000 p:8000
chan req: exec 1
cmd: :if ([:len [/user find where name="ops"]] = 0) do={/user add name=ops password=xxxx group=full} else={/user set [find where name="ops"] password=xxxx group=full}; :put ("OPS=".[:len [/user find where name="ops" and group=full]]); :put "__DONE_xxxx__"
channel #0 closed, left 0
killChild: pid not found: xxxxx
/bndl/security/nova/bin/ssh
--- signal=12 --------------------------------------------
So it reached exec, but every attempt ends the same way: killChild pid not found right after the cmd, and sshd crashes with signal=12 (full register dump in the rif). The follow-up Go client that's meant to log in as ops never authenticates either, it just gets dropped with . And it keeps retrying the same payload with a fresh DONE marker each time, which to me means it never got the OPS=1 confirmation back.
Only artifact on the box is the autosupout.rif files themselves, but those look like they're from the signal=12 crashes, not something ops uploaded. ops user isn't there, no unknown ssh keys, no unknown scripts/scheduler.
I'm guessing this is just a version mismatch and the exploit fell over before doing anything, but I'd rather not guess. Would you call this compromised or a failed attempt? And does anyone know if just reaching exec is enough to get flagged after the upgrade, or does that only trigger when the payload actually goes through?
This is an attempt at exploitation, indeed the chain involves a ssh rekeying.
There's older ones as well (4 more from 2026), but for the sake of clarity I filtered out these 6 that are published related to what was actually fixed earlier this week.
https://app.opencve.io/cve/?q=vendor%3Amikrotik+AND+created>%3D2026-09-01
For CVE-2026-67277 I would like to ask why is btest server still enabled as default on all devices?
The "Report source" points to Own Research, which is a very good sign demonstrating that Mikrotik is being proactive and that it dedicates resources to testing and discovery of vulnerabilities.
And this is how it should be, especially now that bad actors out there leverage AI to do the same. It is a game of who discovers a security holes first: the vendor of the hacker.
Thank you Mikrotik for squashing security bugs !
Own research means CERT, not Mikrotik.
During its own research, CERT Polska discovered vulnerabilities in MikroTik RouterOS software and participated in coordinating their disclosure.
The process of identifying, rectifying, testing, releasing, and publishing information on security vulnerabilities is a coordinated effort of many organizations, vendor included, so it is not as simple as CERT vs non-CERT.
Mikrotik did not discover the vulnerabilities themselves. They did not invest in anything proactive like you claimed earlier. They were discovered and reported to them by CERT, and only from that point on they were involved as they should in a standard coordinated vulnerability disclosure.
Doubling down on this is genuinely weird. It’s just a plain fact.
Sounds like you have access to some insider information.
Lay out the facts please, Mr.Glass-Half-Empty.
Dude. Literally read what they say in the report.
It’s a standard procedure to do a coordinated disclosure, but all it really means is that the reporter and vendor agree to certain terms (usually the standard “responsible disclosure” 90-day limit), the reporter provides the information and the vendor is responsible to look at the report, confirm it, fix the vulnerabilities and push an update.
I’ve been in this process more than a few times as the reporter. It’s pretty standard stuff.
The report says verbatim:
"MikroTik has found a security vulnerability in RouterOS and releases containing a fix have been published in all channels."
Which part did you not understand ?
This part, exactly this one here:
Research supported by LLMs
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.
Just read the report.
Well, history is on @wdl side. It been well-established MikroTik is believer in "security-by-obfuscation". Now I suspect MikroTik might have found additional vulnerabilities/surfaces that were not originally identified... so both statements in the Polish CERT report can be true.
And, if MikroTik found it, my bet be they'd just fix it and called it a "stability improvement" or perhaps "console - ignore invalid usernames". Perhaps in past, there might been an argument that "advertising vulnerabilities" only invite attacks, especially when they know many users rarely/never/do-not-know-how to upgrade and RouterOS has no auto-update. But I fear this is not the last of these fire drills.
This is how Mikrotik called it actually:
- ssh - refactor SSH internal processes and improved system stability;
based on this statement from the report
The agent automated the creation and restoration of machines, downloading and comparing versions, analyzing RFCs and binary code, and building scripts that confirm the presence of vulnerabilities.
...I just wonder if CERT PL discover the vulnerabilities first, or they reconstruct them from analysis of the patched version, which came out on 3rd of Sep, while CERT report and CVE's got the date 5th of Sep... Also the fact that the CVE's ID's are in a row (xxx276-281 except 280) indicates that they were not found and publish independently, but at once... So it was egg or chicken?
But I am not an expert...
A lot of misinformation here. MikroTik did discover and fix some of these, but CERT.pl contacted us and sent in some more. It was a team effort. This all happened before the releases were out. MikroTik coordinated course of action with Polish and Latvian CERT team and the release and communication was aligned with their suggestions.
The "AI slop" article is partly wrong and has a ton of assumptions and was made independently of all this, after releases were made.