Valid point.
Releasing a critical security fix only in a beta branch and in a very recently released minor stable branch (7.20) is rather disappointing. But Mikrotik probably classified it as "instability" rather than a security issues. We do not know.
@infabo, probably because
I get your point. There are also devices which come without default configuration afaik. Like CHR I assume. Well, then it is up to the admin to add proper firewall of course.
But I am more thinking of people exposing webservice for rest-api purposes. Having no user allowed for webfig, winbox, etc. Only a restricted user for rest-api with hardened password. Then there comes a external request and brings down their device or at least the www service.
I understand,
but I think whoever activates the REST service (or others) for external access should have already blocked access from IP addresses other than the authorized ones, or at least done a "knock" first.
And speaking of devices without default settings, they don't connect to the internet by default...
These are more advanced devices, and hopefully those who configure them know what they're doing...
Sorry, but how exactly do we active or deactivate it? As far as I know, rest is the only service which we are still unable to enable/disable?
It can be deactivated starting from 7.21. Currently in the beta version, it's the web part of User Manager (/um/) that cannot yet be separately deactivated from www/www-ssl.
DISCLAIMER: This is MY opinion, not facts.
This bug likely arose from a desire (foolishly, in my opinion) to use the same port for all services,
instead of (logically) using different ports for each service.
On web 80 or 443, the following are listening (if I'm not forgetting anything):
Homepage [http & https]
WebFig [http & https]
Graphs [http & https]
REST API [http & https]
CRL [obviously NO HTTPS]
SCEP [obviously NO HTTPS]
ACME Challenge [obviously NO HTTPS]
Missing on screenshot:
user-manager [http & https]
So, a jumble of things was created that likely attempted to decode the requests
before sending them to the appropriate service.
That's why the content is checked BEFORE EVEN LOGGING IN, hence the vulnerability...
EDIT: added some after see the screenshot...
OT, but from the reports I read, 7.21 deactivates (automatically) quite a few configurations and devices, besides that service. 
Sure, I was joking on the fact that from reports 7.21 often disables (as in won't run/won't boot) the whole device (which is BTW very secure).
beh...
I doubt that people who use âLetâs Encryptâ certificates with ACME automatic renewal know what they are doing when enabling WEB access for that.
And it isnât easy to allow only certain addresses for that, because they âintentionallyâ do not publish the addresses they are using, and randomly change them.
The new feature to enable/disable subservices for the Web Server needs an additional field for âAvailable fromâ (like all services have) so you can set it separately per subservice.
Did you happen to submit a report with regard to UM missing its own control? This seems like an accidental omission.
It might be because UM is in a separate package, and they haven't built the necessary hooks for the extra packages to make changes to the layout of this routeros's menu. I've enabled the UM package to be sure and even with the package installed, there is no User Manager checkbox on this dialog.
But in 7.21 they also built the change where if container is not installed, the VETH tab is hidden from the Interfaces window. So it appears that the presence of extra packages can already influence the dialogs of the core routeros package.
Ok. Against my (usually) better judgment, Iâll bite.
15 days is considered fast. There is a Vendor In Seattle Who Shall Not Be Named that issued security patches scheduled monthly. This means that even is their devs work infinitely fast, at least 50% of bugs will not be fixed in 15 days. If you assume it takes at least a week tp actually research and patch something, 75%. Other well-known vendors, like the one recently acquired by Broadcom, release patches quarterly. Itâs not an accident that usual responsible disclosure guidelines say to wait 90 days, and if the recipient has a reasonable request, more.
Yep. Should be done.
The changelog in mainly meant for a technical audience. Literally writing âCVE-xxxâ in the work item kind of gives the purpose of the fix awayâŚ
You literally say that per normis, the investigation was done. He wrote down the results. You may think he is not being truthful - I canât speak to the facts either way. Who should investigate? The Dutch Navy?
The state of security research has many problems. Itâs not uncommon that some make only a cursory attempt at contacting the vendor. Many vendors donât actually respond, and the only way to get them to take any action is to name and shame. This creates resentment on both sides. Iâm only talking generically, and I donât claim to know what happened here.
What I can say for sure is that I have alerted Mikrotik to issued that could have security consequences in the past. On their page concerning this they say that they will attempt to address these reports âwithin 24 hoursâ. In both cases they kept to this.
Yeah sure. Try this with other vendors. If youâre a big enough customer or a publication with enough readers, you might get a PR non-answer.
Altogether, I donât really get what you want to happen. âTo give security more priorityâ is such a vague request. What I actually understand is âthere should be not more security issuesâ. Thatâs not going to happen.
This way an issue that presented a DoS with an out-of-bounds read. We hear about way more serious issues with the famous enterprise fw/utm/etc. literally monthly: RCE, user credentials lost, central manage server key compromised, etc.
There is some speculation that this CVE could in some way lead to RCE. This is not yet the case - it would require some creative chaining of exploits.
It was handled roughly in the way such a disclosure should be handled. Yes, the fix was published in beta first - once a vulnerability is widely known, thereâs no reason to keep testing the fix confidential. Security fixes need testing as well, especially since here two fixes happened: the JSON parser was fixed and more granular access controls were introduced. After limited testing, it was backported to stable. You may think that it should have been backported further than the currently supported âlatest stableâ, but thatâs just rehashing to âIâd like a v7 long-termâ statement in the context of security.
Thanks for your extensive response @lurker888.
I tried to describe what I want in my post: Most importantly, as we both agree, Mikrotik should have released a security advisory shortly after disclosure and update it as new info becomes available. This would resolve 2) and probably also contain details on 4) and 5) - so already 3/5 of my suggestions would be fixed.
Regarding 1), I see your point, but other vendors not fixing fast isnât a good benchmark.
Regarding 3), as I said, it feels Mikrotik doesnât treat it as a security issue.
That said, I still think 1) to 5) in combination[1] indicate that security processes and practices could be improved. My request may seem vague to you because itâs just an assumption and I think itâs on Mikrotik to clarify and build trust.
1) to 5) arenât unrelated issues each affecting separate CVEs. Instead, all affect the same issue, so we shouldnât rate them as if they were independent. âŠď¸
What's new in 7.21beta5 (2025-Oct-30 15:16):
www - process REST API requests only after user authentication is completed;
