But what makes the VPN interfaces more secure than the admin interfaces?
Better programmers on those jobs? Software from other sources, not internal to MikroTik?
There must be some reason why there are leaks in admin interfaces all the time. And not in VPN.
Or maybe there are, and they just have not told us? ("improved stability of" bullshit)
It changes nothing, leaving 22,80,8291 isn't good idea - it can be exploited on ANY DEVICE, or used in "legimate access" using weak/leaked passwords. This isn't MT fault.
Back in 2018-2019 when winbox vunerability was discovered, seeing impact - hacked devices used as proxies, ddos dns realys - we started dropping windox,ssh,api, in ANY direction in or out, posted info about vunerability on FB, advice to update devices if ou have any.
Feedback? 0 thanks, 50 complaints:
-"i've lost access to device"
-"if it works, i won't upgrade"
-" i dont remember my password"
Due that, I am huge fan of device-mode, even if sometimes it make some things harder.
MT biggest advantage and also disadvantage is that you can configure almost everything, but also on dangerous and insecure way. Many people coming from soho routers even don't realise that.**
**
If somebody disables firewall/exposes service ports to Internet, it's not fault of MT or AI agent which propsed dangerous solution - at the end of the way, responsible is always on person who connected it that way.
I agree... AI often suggests such stupid firewall rules... when the existing ones are impenetrable...
The problem is always the user changing them...
Should set device-mode to default rules. They can't be deleted or modified...
You’re once again mixing Apples with oranges.
Users failure to follow best practices does not equal the failure of responsible disclosure by the vendor.
The complaint you see here is not about the existence of the vulnerability, that’s nothing special on its own and it happens to any company and product. And it’s also not about best practices. The complaint is rather mikrotiks way of handling the disclosure.
I'm not mixing anything - everything can be vunerable at any moment - so if there is confirmed vendor info about possible vunerability - trace is known:
-backup
-check backup
-check standby device in case of problems
-upgrade
-check if everything works normal
Info what was vunerable may come later - what diffrence if it was winbox or ssh - **it shouldn't be available from untrusted networks.
**
As I know for now, hacked are devices with exposed 22/ssh....
I think this is a good hook to talk about splitting control-plane, data-plane, management plane.
Reserving computational resources for that(cpu affinity and c-groups).
And VRFs for that different purposes also.
I don't know exactly. But my feeling is that RouterOS is walking to that diection.
And speaking from the perspective of network equipment (routers, switches)... there aren't many kilometers left to get there.
More related to the topic 
All devices running Stable, Long-Term and Long-Term V6 are upgraded to new build and apart of the guy who upgraded forgetting to inform users no issues, naming no names here of who messed up!! 
Devices: RB3011, RB4011, cAP AX, cAP AC, HEX S, wAP AX, CRS326-24G-2S+, HEX PoE, HAP AX Lite LTE6 and hAP BE Lite. All upgraded from respective previus build.
It makes all the difference once you know it’s either winbox or ssh.
And that’s the whole point. Mikrotik did not disclose a thing till they were pushed to reveal some more details, and even that came only after someone discovered they were compromised - another detail that was missing from mikrotiks “disclosure”.
You need to take a step back and look at the big picture, because if it was in a VPN service for example and Mikrotik wouldn’t have said so - you’d be pissed. It’s their policy of handling the disclosure which is extremely concerning.
On a underlay-overlay network with several devices...
VRF for management do this job so elegantly.
Several vendors has their own default management-vrf.
Its not far for MikroTik to do that.
DCN concept need to get into mind of MikroTik Team.
Good idea for home users
What?
This?
Should set device-mode to default (firewall) rules. They can't be deleted or modified...
Maybe the VPN interfaces don´t have access to the user authentication code that an admin interface have? Maybe the bug is on the system authentication part, not the network/interface part.
This could lead to a situation where (say, I'm making this up) an "out of bounds" error could be used to auth some fake user, but would do nothing on Wireguard - because it doesn't have an user to authenticate, and so have no privileges to be exploited.
I just made this up (PLEASE, people, I'm MAKING THIS UP! DO NOT assume is true), but You got the idea.
Well, the VPN code suffers from the same risk of a possible out-of-bounds write that could lead to execution of code in a process running as root, or even in the kernel itself.
It would be best when every process in the router runs at an unprivileged user whenever possible, but I do not think that is happening now. E.g. the entire web interface could run as an unprivileged user (as it normally does e.g. when apache2 is used as a webserver) but it would require some agent that passes on configuration requests to higher privileged contexts, and probably the constant pressure to limit code size would be an argument against that. Similarly, a service for OpenVPN or Wireguard can run as an unprivileged user.
After upgrading from 7.24.1 to 7.24.2, now the 10gig sfp+ fiber link between my 2 switches is flapping.
CRS328-24p-4s+
CRS312-4c+8xg
The same thing happened to me with the hAP ax³. I started the download, and when the router rebooted, it took longer than usual; upon checking, I saw it was still on version 7.24.1. I tried again, and it did update. It was concerning, though, so I wrote to MikroTik support.
I don't know if is related to ROS v7.24.x, since I thought it was fixed in 7.22.x, but in my hAP ax3 with a pi-hole container installed and no apps, in export rsc file are present all scripts for all available apps in catalog.
Is there a fix?
Thank you
I had similar issues with PPPoE. Constant flapping after upgrading to 7.24.2. A downgrade to 7.23.5 fixed the issue.
What router model? My PPPoE (over VLAN) is perfectly stable on a RB4011 running 7.24.2.
DHCPv6 over PPPoE as well. Gets its usual prefix with a 24h validity.
Since 3rd of September there is information on the Mikrotik\Support\Security and there is the text "steps after upgrade" which helps you to check if your device has been compromised. Also the information "most configuration are not at risk" refer (I assume) to default configuration of the devices intended for home users, which have already pre-configured firewall, restricted access to mgmt from LAN ports etc. And such cfg is considered as "not at risk" even from perspective of this vulnerability.... So yes, having cookbook leave our mind in better shape, but on the other hand I don't find information from MT inadequate... together with the info on the forum, you can get quite good information about the situation...
I observed this on a Chateau PRO ax device. Not only was the PPPoE flapping multiple times per hour, but all the etherX interfaces were flapping too. Thankfully it has been rock solid since downgrading to 7.23.5.