Sorry, only MT staff can help you.
I can confirm, "/ip service" filters the IP before it is passed to the respective service. It is safe against attacks.
Thank you for your response
Well shit. One of my two MikroTik Internet routers has an "ops" user added, disabled with a comment: "Disabled as known malicious configuration". This disable and comment was done by the upgrade yesterday.
This router has many ports open: a custom SSH port, NAT port forwarding, wireguard, and IPSec/IKE.
Default user admin is disabled. SSH allows key pair login as well as password login.
I don't see anything added in scripts, but if the vulnerability was root access, anything could be done. I'll export my config by script and net install the router. What a pain in the ass.
The other router does not appear to be affected. It has the admin user deleted and only IPSec/IKE ports open. SSH allows key pair login as well as password login.
I updated both routers on 2026-09-03 at approximately 1400 UTC.
The ops user was last logged in on 2026-09-02 at 1238 UTC.
Edit: turns out I had SSH firewalled from the WAN on the router that was not compromised. I think we can pretty safely assume this was yet another Dropbear SSH vulnerability. If MikroTik didn't sell devices with only 16 MiB of flash memory, maybe we could have OpenSSH instead...
Edit2: I also had "fail2ban" firewall rules working for SSH, so it seems this was an easy vulnerability rather than any brute force component needed.
No. This was already fixed in 7.21.4 and 7.22.2
Just ssh is enough, all the services using the affected corelib.
Do you think RouterOS uses dropbear?
It is well known that it does use a fork or stripped down version of Dropbear SSH, yes.
According to this analysis, it looks like a combination of weak RSA public key exploit and overflow into tftp to run a privileged script. Indeed I had old RSA keys enabled because MikroTik took so long to add support for Elliptical Curve keys. Sigh.
Edit: well, apparently not. After migrating to RB5009, I never added the SSH keys.
Well known? Well known are facts. You made a claim without proof/evidence. Dropbear is not mentioned here: https://mikrotik.com/software/legal
What version were you on prior to updating?
Are you sure there wasn't anything else open?
Well then maybe it isn't. Either way, it's not OpenSSH, and that's pretty alarming.
Clankerslop, incredibly DANGEROUSLY misleading article. The author should remove it.
I identified the actual issue and recreated it locally: It is related to SSH and allows any unauthenticated remote attacker access to a shell. It doesn't matter if you use passwords or keys. If SSH can be reached, you are vulnerable until you update.
If you check compromise logs you will see user 0 logged in from -2@somehackerip over SSH. -2 is also a command line argument to /bin/login, and the patch was preventing those from being passed as usernames. Fortunately full exploitation is not trivial, so I won't explain further, but clearly threat actors have also figured it out by now.
This is why we need CVE disclosures and more information. Otherwise we get dangerous misinformation where people think "I have ssh with a key login, or I have telnet disabled, so I don't need to update", which is WRONG.
According to a guy on reddit it's already in the wild and abused Reddit
I think it was 7.22.x. Apparently my auto update script stopped working, sigh.
And yes that's "all" that was open, lol. I'm assuming you meant that question as a joke.
Good article, was a nice read with insights. And the article confirms a "gut-feel" I always had: why has the "read" group "test" policy rights? I always create a group called "read-only" with only "read" policy (besides login policies). I always suspected someone can do harmful with that.
Obviously MikroTik is performing remediation operations on the devices during the upgrade, but does anyone trust this is enough? I need to leave in 3 hours and I really don't feel like net installing and reconfiguring before I leave....I guess I should just bite the bullet and do it.
I do hope you can control the auto update script, so it just not upgrade to a new build when it released. With so many problems just after a new release, you may lock your self out or brick the router.
Read forum some before you do the upgrade.
The vulnerability written up in the article is a real one (note: a different approach was taken than what I have confirmed, but the core primitive is valid), if you are using RSA e=3 still then you've ignored 20 years of security guidance and I don't know what to tell you there.
This is what people actually needed to worry about with regards to SSH if fully reproducible (confirming now for myself).
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).
But I will do what the author of that article should have done, and keep my mouth shut, it's being handled, and if you have followed mikrotik's guidance you are fine.