Sorry, It's not the port.
I'm sorry also, you didn't get it.
COME ON!
OF COURSE this is not meant to track each and every update, not stable and not even long-term.
It is only intended to install critical updates, as written above and in many other topics.
This problem only occurs when you try to update to every RouterOS version. There should be a new channel that only has critical updates, preferably for each major/minor version. So that channel would have a 6.49.21, a 7.20.x, a 7.21.x, a 7.22.x, a 7.23.x, a 7.24.x version etc which patches the critical errors in that x.xx version and nothing more.
Or only for some major.minor versions? Guaranteed for a set period of time? Sort of what long-term means for every other piece of software? 
If that channel actually does that exclusively... Well, it would make sense...
But the rush to release a bug fix (no matter how important) without even minimal testing (which is what we expect from MikroTik) leaves a problem.
Summary: Without increased quality control, it's all pointless, even counterproductive.
https://www.kombo.lv/lv/profile/40003286799/mikrotikls
If MikroTik really has 384 employees,
I wonder how many work in Hardware, how many in Software, how many in Marketing, and how many in Administration... 4/4/372/4 ?
Well, there are some wellknown issues when upgrading, because major things have changed for some subsystem, and the automatic upgrade should not attempt to upgrade past those markers.
MikroTik know themselves what versions these are. E.g. 7.12 7.20 etc. And also some in the 6.x series.
Which already for quite a while is not really a problem since access from outside is blocked ??
Defconf does this for as long as I can remember (but I admit: I haven't been using ROS nearly as long as most of you)
This is not the base problem, I think.
@rextended
The concept of "work" in marketing has always been debatable, nowadays it is better to say "do something in marketing" to distinguish from those that "do nothing in marketing" or, if you want both groups together, "employed in marketing".
Effective from 6.43 on 2018.
Previous versions already had something,
but with the confusion of the master/slave bridge it was more of a mess than anything else...
From 6.43rc3 (2018-Apr-20) defconf:
#$addConfLine (" filter add chain=input action=accept protocol=tcp dst-port=8291 comment=\"defconf: accept WINBOX\"")
is added a # in front of this.. rule...
All on (2015-05-29)
:if ( $wanPorts != "" ) do={
# add NAT
:foreach i in=$wanPorts do={
$addConfLine (" /ip firewall nat add chain=srcnat out-interface=$i-gateway action=masquerade comment=\"default configuration\"")
}
# protect WAN port
:if ($secureWAN = 1) do={
$addConfLine (" /ip firewall {")
$addConfLine (" filter add chain=input action=accept protocol=icmp comment=\"default configuration\"")
$addConfLine (" filter add chain=input action=accept connection-state=established,related comment=\"default configuration\"")
:foreach i in=$wanPorts do={
$addConfLine (" filter add chain=input action=drop in-interface=$i-gateway comment=\"default configuration\"")
}
# add forward chain rules
$addConfLine (" filter add chain=forward action=fasttrack-connection connection-state=established,related comment=\"default configuration\"")
$addConfLine (" filter add chain=forward action=accept connection-state=established,related comment=\"default configuration\"")
$addConfLine (" filter add chain=forward action=drop connection-state=invalid comment=\"default configuration\"")
:foreach i in=$wanPorts do={
$addConfLine (" filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=$i-gateway comment=\"default configuration\"")
}
$addConfLine (" }")
Groups didn't exist yet, so one rule was made per port, but it was a start.
So, basically, the default firewall (which has since evolved) has protected the administration ports from the outside at least since 2015.
The real problem is that the firewall updates, or rather, it only sets itself up when you reset it.
IT DOESN'T UPDATE when you upgrade or update, whatever you want to call it...
This is actually a big problem... THINK ABOUT IT: Maybe the versions fix bugs in SSH and other things,
BUT THEY DON'T CLOSE THE PORTS...
When will the next massive bug occur?
The problem here is one of definition, and process. Not channel labels. It was already choice not to patch 7.21, and instead MikroTik patched 7.23 and bumped it long-term. So IMO some new vernacular is meaningless without the intent behind it. ;).
Once again the firewall protects you from WAN, not the LAN. And given a 10-year old kid and his AI agent could easily take control of their parent's router at this point, without knowing the password. An auto-update at least limit the window of exposure beyond just hoping ALL owners of MikroTik are keeping up daily.
Again it's all predicated that you assume it's okay for unauthenticated access from the LAN, and all users are diligent about upgrading (and reading email/etc to even know).
Further, the same was said about device-mode...a good firewall protect you, so why disable features? But yet some features are disabled. And it was suggested then that auto-upgrade would be better approach for future attacks to actually solve the "never upgraded" routers that amplified the Maris attack.
If one lesson from the 6 CVEs is not that some type of built-in automatic upgrades in needed, that be a mistake. Since I do follow the forum, I know to upgrade...but 90% of user likely are not watching MikroTik topics. But I doubt the rate of cyberattacks will be going down, and think chance of AI finding more bugs in RouterOS is high. Some supported scheme to ensure routers have the latest security patches is sorely needed.
IMO ROS auto-update as device mode setting and enabled by default for Home and Basic device modes; and only if long-term or stable release channel is selected could work if MT actually releases stable versions - like doesn't introduce mentioned recent critical connectivity bug for IPv6. In this case enterprise/non-SOHO devices will have this option disabled by default and it will require manual attention from admins as they are doing now; and non-regular Joes will have option do disable this as well to control updates as they like. Now how is this realistic considering releases from past IDK...
Also it would be nice that MT introduces basic config audit tool in ROS which will analyze current config and report to user with some risk score which config introduces certain risks, like some exposed service to WAN or missing some critical FW rule that blocks input from WAN, etc...
True. But even with this bug, IPv4 still work to auto-update again assuming dual-stack. So it "fix itself" depending on polling interval. Plus... if you're smart enough to have a pure IPv6 setup on RouterOS, or more generally make substantive changes to config... you're likely smart enough to disable some theoretical auto-update=no.
And the reverse also happens with auto-update. If our "average Joe" just uses the factory version his router came with, and that version does have some bug/instability/etc issue. In many cases, a fixed in newer version may have fix/improvement. Just saying it's not all "upgrades are buggy"... old version also have bugs too.
Add: Router need to be upgraded once, before is usable...
But if is not usable... How to configure it to go on internet for download upgrades?
And all the millions of devices already installed?
Yes, but what if connectivity breaks for both stacks... Maybe to introduce easy way to revert to previously installed version when something like that happens? Also it would be nice introducing some setting along with auto-update to set time when ROS will reboot to perform update with default to some time in the middle of the night so that will not break internet connectivity unexpectedly.
Right now the logic for "device mode flagging" seems to be baked into the routeros package. What if the information for the "flagging" functionality could be updated seperately and automatically. Mikrotik could publish new ruleset, device self-update their flagging-db. This would at least avoid a complete take-over of unmaintained devices. These devices would continue working - with all restrictions of the device mode flagged state.
If they added auto-update along with the device-mode changes, there already be some number /[1-9][0-9]+/ with some kinda automatic update that would have applied the patches in this thread... if it was done along with device-mode. You have start somewhere
If you have some standard home/SMB internet like cable modem or starlink, I have seen at least one case of someone just use the sticker Wi-Fi name/password, and plugins ether1 to the modem/dish/upstream... Not sure % of routers are never logged into but higher than 0%.
It's @Larsa that thinks it should start with different defaults. I'm more in the auto-update=yes|... camp. And if there was a more modern controller than Dude... I might have say that's where this gets managed... but alas there is not some controller.
And I think my main point is that "something more" should be done to improve upon the "email everyone" approach is needed.
Good point / idea! I do know one check is for ops as a user and will flag... but it does not know if the user came from an attack since I just added one before upgrading in local test (with fresh CHR unconnected to internet) which caused the flag.
Let me remind the words of JFK:
Don't ask what Mikrotik can do for you, ask what you can do for Mikrotik instead...
...in other words, for example "scoring" of configuration (some review) can be done by anybody interested using AI (at their own risk, of course) - guidelines are everywhere and the effort needed is decreasing....
Maybe forcibly invoking something like a captive portal with the “critical security update” messaging would be a good idea.
The user will have the option to postpone or ignore it if they wish, but that would make sure the message comes through without prior registration or proactive action on their side.