Couldn't agree more.
I've been reversing this myself in the last few hours. There is more than what Nick have found and covered in his article.
I've never had a problem with upgrades on stable. I'm running a fairly basic config, no BGP or OSPF. Just some static routes, wireguard, IPSec for a site-to-site connection, and port forwarding to services on my server.
My script does automatically backup the config before upgrade. And at least on the RB5009 we have partitions since the storage isn't anemic. Whenever I make a config change I always copy the running software and config to the other partition first as a fallback. I haven't written the complexity into my script to do that for the automatic upgrades, though. Maybe I should.
I don't even understand who has a rsa key generated with e=3 on purpose?
imported the same 2048-bit RSA public key with exponent e=3.
My compromised router model was RB5009. I changed partitions from 2 to 1 (not sure if this was really necessary), and then did netinstall to the latest stable, with no default configuration.
After logging in, I saw the following in the log:
2026-09-02 09:57:16 system,error,critical configuration flagged, check all router configuration for unauthorized changes and update device-mode
Upon investigation I found that I had to use /system/device-mode to unset the flagged parameter.
Netinstall was successful, and there was no default config. I am surprised this parameter was still tripped. Is that expected?
Also I find it to be a pita that secrets and users are not exported by default. Now my IPSec tunnel won't come up, and I had to recreate my user login. Ugh.
Update:
I've only been able to reproduce this from a configuration-dependent authenticated context, which aligns with Mikrotik's messaging. I am not saying that it's impossible as an unauthenticated remote attacker, just that I can't reproduce it, nor can any amount of agentic AI I throw at it.
Mikrotik have taken a step in the right direction with this security update by being more transparent than they have in the past and are taking all the right steps to handle this properly in my opinion. Once the patch window is up, I'm sure more information will follow.
No, it's a bad article, see my post.
Ugh.
I need to upgrade, but when I do, the Mikrotik never cooperates with the cable modem so we had to stay on 7.22.1. Anyone know if it's been fixed?
Without "test" policy it is impossible even to run ping command. If "sniff" policy is missing then read-only user is not able to see traffic counter data (on interfaces etc).
test - policy that grants rights to run ping, traceroute, bandwidth-test, wireless scan, snooper, fetch, email and other test commands
sniff - policy that grants rights to use the packet sniffer tool, torch tool, traffic generator.
Continuing the discussion from Important security update:
I have to agree with badinfo. Not having a CVE disclosure really creates a bad situation, FOMO patching.
I know. But my use-case for these read-only users do not need ping or packet sniffer.
Just to be clear...everyone should be careful with a myopic focus on "SSH" since @normis has been "clear-ish" that's it's "management protocols" effected.
While SSH may be the "most common port" that might be open to internet, that may not be the whole story. MikroTik is typically not alarmist... so I'd take the advice to patch seriously here.
"improve stability" across all the core services... the LLM revolution has arrived, it is reckoning time for Mikrotik's home-grown daemons full of security holes.
Correct, which is why I said this
And depending on what version you were on before, there is at least one more as well that's very concerning (won't mention where).
Left intentionally vague.
And although some of what other users have written about the particular bugs in SSH are true, they are missing (or intentionally leaving out, not quite sure what's going on) a very important configuration that needs to be present for it to be exploited (happy to be proven wrong), it's not "if ssh is exposed then you're vulnerable from anywhere" like they claim.
Ironically there is a lot of "bad info" (lol) spreading, which is why we should wait for Mikrotik to release more information after a reasonable amount of time has been given to ensure patching goes smoothly.
after upgrading 7.24beta3 to 7.25beta3 I lost an App that I was using... (S....M....).
If that was not part of the vulnerability and it was removed by mistake can it be restored?
Ironically, I just got the email notification on this . . . about 36 hours after the fix was released . . .
Definately take it seriously.
I had SSH exposed on a custom port and WWW, with a fail to ban type system on them.
Got pwned.
How is that ironic?
Seriously late, and after we all know. The notice should have gone out first, not after the fact.
But, better than nothing, I guess.
Ironically,
on various forum... all attacked on the Sep-2...
Like the day the fix was build...
As another user wrote in a link to a site posted earlier, by creating alarm, it automatically revealed the vulnerability by "DIFF" and launched the attack...
Otherwise, these "ops" would have existed days earlier, not coincidentally after the beta release with all the alarmism that entails...
But these are coincidences that have nothing to do with it.