Very serious must be a vulnerability, such you report to security@mikrotik.com
Thanks, that's where I submitted it.
Some stats that contradict that:
There are 92 RouterOS CVEs -> only 22 of them on made it to /supportsec -> and only 19 of those made it to changelogs; 62 appear in neither.
Of the 39 rated CVSS > 7.0, 21 of them appear in no vendor channel at all.
CVE-2025-61481, CVSS 10.0 (WebFig cleartext HTTP by default, credential interception) -> not even on the advisory page.
Not to mention some of these "stability" fixes... not about stability at all, there is a very long track record of issues being silently patched. Some users/operators might even be working in critical infrastructure and not have a clue about something they should be made aware of.
CVE-2026-39042 a DoS in unflatten() in libumsg.so, affecting "7.21.x before 7.21.4 and 7.22.x before 7.22.2" - exactly the two releases from 2026-04-21/22 whose only related changelog line is *) www - improved service stability when cancelling REST API sessions. The fixed shipped in April, identifier filed by a third party in July, they never connected the two.
CISA is now assigning CVEs for RouterOS API flaws that haven't been published, see: CVE-2026-16347, and CVE-2026-14227 the assigner is CISA ICS-CERT.
Yes we know that. Useless to bring that up over and over again, it is how it is and it seems it is not going to change.
Just annoying to see
Also annoying that problems with API or admin interface are usually brought to attention as critical flaws that require quick action and updating, while in fact such flaws are usually not exploitable from outside.
It is my firm belief that "security researchers" are only trying to boost their own ego and/or trying to get budget for more work, and not really intending to improve security.
This is a useless CVE. Out of the box there are two other channels for configuring the devices, both secure, with encryption, namely SSH and WinBox. No one is forced to use WebFig.
And after the initial configuration, if you love Web interfaces, you can disable the api and www and turn on www-ssl with a proper certificate.
The other systems that claim to offer HTTPS out of the box of course only have self-signed certificates at the first login, which means MITM stealing the credentials is possible too and that in turn is less secure than WinBox!
I disagree hard. As a (professional) web developer, webfig storing my password in browser local storage and transmitting cleartext makes me want to travel to Latvia and visit the developer who implemented this to give a free lesson on OWASP best practices.
That is what I mean. Useless ego boosting, not addressing an actual problem (WebFig is normally only accessible from LAN and on today's switched LAN nobody can intercept passwords).
And indeed, https on local devices is only introducing a new problem.
What about unauthenticated remote code execution as root - would that qualify as a meaningful security concern? Hypothetically speaking, of course. Would you want to be made aware that something like that was even a possibility? Or just silently patched out as a "stability" issue?
I agree that not every vulnerability warrants a "holy shit, man your battle stations" level response. But a flaw with that level of potential impact should not be dismissed simply because exploitation is uncommon or requires a sophisticated chain; even a small credible risk deserves attention.
That said, I don't think I'm going to change your mind, so I'll leave it there.
Mikrotik usually patches actual vulnerabilities. (By this I mean that I am unaware of any instance where this hasn't happened.)
These admin interface/api cves are simply irritating. E.g. for the one you quoted, the problem is that users expect to configure their routers from a browser, and https assumes that the server you are connecting to has a public fqdn, which mostly presupposes a routable IP, and that a cert has been requested, issued and installed. This is not really possible with a router. It's not a vulnerability, but a limitation. As others have said, you either trust your local network (e.g. configure the router by directly plugging your laptop into one of its ports) or you can use winbox/ssh.
I wasn't claiming issues like that go unfixed - they mostly do get fixed, and you can go and diff the binaries and find out exactly what has been fixed if you want, I have.
My point is narrower than "Mikrotik hides bugs": an operator reading every release note and tracking every CVE still can't tell whether a given upgrade is urgent, because the advisory page and the release notes are disconnected systems and nothing bridges them. The advisory says "upgrade to 7.2.whatever or later" The 7.2.whatever notes don't say why. If you're someone who actually cares you are left diffing the binaries yourself or upgrading on faith.
And "trust your local network or use Winbox/SSH" is a threat model, and certainly not a universal one. It's fine for a home router. It doesn't survive contact with an ISP, or a hosting provider, or anyone whos management plane is reachable by more people than they can vouch for. Those operators need to know which upgrades are absolutely necessary.
I think people following the long term don't want to be bothered by this side-dicussion. A separate topic to discuss "how to improve ROS changelogs" is long over due.
It has been discussed many times, and the result has always been zero.
The CVE numbers are referenced in both of them.
In case the CVE is so vague that what exactly is referenced then it's not referenced. If Mikeotik doesn't think that it's an actual security issue, again, it's not referenced.
It is documented through many unfortunate cases that removing or downgrading a CVE is practically impossible ("the assigning authority doesn't perform independent research, and it's better to err on the side of safety") The only way to control (and thus have good quality cross-referencing) is to establish a CNA (CVE Numbering Authority) as many bigger vendors do. Until then, it's pointless to try to keep up with every bit of lunacy filed.
This is not what's usually referred to as a threat model. Nevertheless "it's fine for a home user..." arguments are reductive: it's only there for home users. If "your control plane is exposed..." then you shouldn't be using it, restrict its use or disable it altogether.
This is like saying Wordpress is insecure because once you expose it to the Internet without a TLS terminating reverse proxy, login information can be snooped on.
While upgrading an hEX PoE from 6.4X to 7.21.5, I've observed the following "regression" or "feature change" (see hEX PoE 7.21.5: voltage_too_high ).
In my use case (powering AP with a PoE-powered hEX PoE), this is a show stopper.
After upgrade remote CRS326-24G-2S+RM v7.21.4 LT -> v7.21.5 LT - boot only in NetInstall mode...
Remote configuration of network equipment for long-distance travel 
Is anyone experiencing crashes on the CCR2216. We've had a crash on 7.20.8 LTS and then upgraded to 7.21.5 LTS and it crashed about 3 times in the span of a month. I've opened up a support case on JIRA 3 days ago with the autosupout file and there has not been any response.
Pretending to be one of those doctors who, even without a proper diagnosis, prescribes fever reducers and painkillers for almost any complaint they couldn't identify...
Perform a net-install on that box.
Make sure it is running the same version of Current-Firmware and RouterOS.
Pretending I’m one of those doctors who—even without a proper diagnosis—prescribes fever reducers and painkillers for almost any complaint they can't quite identify...
Perform a net-install on that box.
Make sure it’s running the same Current-Firmware and RouterOS versions you’re currently using.
Have backups in both .backup and .rsc formats.
"Are you sure that will fix it?"
- Absolutely not!
But I’ve lost count of how many times I had no reasonable explanation for crash issues, yet doing this made the problems magically disappear.
"Are you sure it won't cause an even bigger problem?"
- Absolutely not!
But historically, I’ve only made the situation worse once when performing a net-install. And I’m pretty sure that was due to flash memory fatigue.
So, I think it’s unlikely anything bad will happen.