Yes, for that same reason I keep literally nothing on the device (no files, nothing, just the operating system + wifi-qcom-ac). Free space currently (with 7.21.5) is 140 KiB. I usually trigger the updates with the eworm script for capsman updates, was thinking if that could have caused it (but it never happened before)
sorry to be pedantic, but what the heck does "home user" mean in this context, is it:
- User at home using Mikrotik as their router
- or a Mikrotik with "Device Mode" set as "home"
i.o.w. a device set as "advanced" as example in device mode is not affected?
In a professional manner it would be stated like "users with no services exposed to WAN" are not affected".
my understanding is it "might" be ppp related, so what about a BNG device terminating PPPoE for customers that is not directly connected to internet side, or L2TP vpn server devices?
Or
- Device running with unchanged default configuration (except for e.g. wireless passphrase)
?
and a device with default config, only changed from "home" to "basic" for troubleshooting purposes still not affected?
I have successfully upgraded the following routers to 7.21.5:
1 x RB1100AHx4
1x hAPac2
No issues with either, was concerned about the hAPac2 as its about 300kms from here but it came back find after about ~2mins
no issues upgrading all my AX3, HEX S, hap AC, and old RB750GL.
lot of HAP Ac2 upgraded only the routeos and the qcom got disabled for no disk space. did clear console and freed about 100kb... but nothing happens. I did downgrade to 7.20.8 and stopped there. The device is remote and cannot netinstall.
That is the issue that I met from 7.20.4 to 7.20.5 on a lot of hap ac2. I didnt met any other issue on this particular release.
I'll settle for just some info on how i could mitigate the issue while trying to get the updates rolled out. How do i know Ive been compromised >?
ie DISABLE ALL PPP connectivity like SSTP/PPP/IPSEC
If you using WG or OPENVPN your ok.
Check XYZ
This issues has been around since what versions ?
The lack of Any details raises concerns of what other information..... we may have never been informed of.
Apparently the issue has been around "forever", as there also is an updated 6.49.20 version.
The big problems is we have not been told what could go wrong. Denial of service, Unauthorized PPP session giving access to network but no immediate security issue, Running code as root on the router able to do everything, we simply don't know.
If it is the latter (it probably is...), of course it still isn't known what compromises to look for as long as there is no exploit in the wild.
Please advice if it's safe to upgrade to 7.21.5 long-term?
My device (normal home use connecting to ISP via PPPOE + CONTAINERS and IPv4/IPv6):
router] > /system/routerboard/print
routerboard: yes
model: RB5009UG+S+
serial-number: HJY0AR6EHAW
firmware-type: 70x0
factory-firmware: 7.18.2
current-firmware: 7.19.6
upgrade-firmware: 7.19.6
Thanks
Hello,
I noticed that it is not possible to create new custom skins in RouterOS 7.21.4, and the issue is still present in 7.21.5 Long-term.
After designing and saving a new skin, it does not appear under Users â Groups â Skin, making it impossible to assign it to a group.
I have verified that:
- Rebooting the router does not help.
- Logging out of WinBox/WebFig does not help.
Is anyone else experiencing this issue, or has MikroTik changed how custom skins are handled?
If this is a bug, it would be be great to have it acknowledged and fixed in a future release.

Have had at least 2x CCR's (CCR2116 and CCR2216) start crashing after this update with sfp interfaces flapping until a physical reboot was done, this includes after updating Routerboot version.
This would be standard practise - the specific details of the vulnerability aren't disclosed until there has been a reasonable amount of time for users/providers to update their devices - add to this it's holiday season in Latvia right now so I would expect the CVE detail release will probably be a few weeks away.
Perhaps this is caused by a very niche/specific configuration on your CCR devices?
I applied this update to a CCR2216 running l3hw offloading in production just over two weeks ago, the current uptime is 17 days and it has been rock solid since.
It would be interesting to know if you've found the cause and how exactly it is "crashing"?
As per the previous message - sfp interfaces all start flapping at the same time, so anything that doesn't have ethernet connected + OOB access requires a physical reboot. Nothing specific to those devices, I updated a fleet of about 350~ CCR's to 7.21.5 over a week, and of those only 2 (different models, some of these issues with older Routerboard firmware, some more since updating that to 7.21.5 also).
Supports recommendation was to simply move up to stable rather than long term - but the locations affected again don't have much different to the others (services/protocols in use are identical) aside from the specific IP addresses in use.
I will say I have a number of other locations that touch wood seem to be running fine so far - but the 2 that have been affected have now had the same issue happening multiple times over.
Are mikrotik usually responsive on jira (their support portal)?
I've submitted something rather serious, and I don't want it to sit in a queue forever, if so I will try to reach out on separate channel.
Cheers
With my experience, their response time could be anywhere between 2 to 3 days, may even be longer ![]()