It's mind blowing how every company seems to not understand that people value transparency. No matter how big of a fuck up, you can play your cards right and it'll be "fine".
Historically moves like this always backfire, exactly as seen in this thread. And still they double down on it. Amazing.
WHAT services? is Wireguard affected? DNS? WinBox? SSH? NTP???
sorry, it's absolutely absurd to release what is apparently a serious security update with no information to allow users to gauge how exposed we are or how urgent this update is.
Maybe this thread can give you some clues - https://forum.mikrotik.com/t/pppoe-service-hacked-27-27-of-april-2026
This part is the best one!
All right, move on... Nothing to see here! Please disperse!
There's nothing to hide. Any script kiddie can run both versions of ppp binary through BinDiff and the differing function is clear as day. Literally 0 skills required to locate it. The fix itself is simple and very obvious, anyone with any amount of experience will instantly recognize flaw being fixed, and if they lack said experience they can ask LLM model from 6 months ago and it would have 0 issues pointing it out.
We're living in times where I could literally automate diffing RouterOS releases and have PoC ready faster than most people would be able to patch it, regardless of whether MikroTik includes it in changelog or not. The obvious answer to such situation is to make it obvious to everyone what flaw is, what to look for (IOCs, etc.) and that they should patch ASAP. What they're doing here is literally giving bad actors advantage.
This had to happen sometime between 7.15.3 (working) and 7.16.1 (not working). Interesting that nobody raised it before you.
I am assuming that you refer to the fact that router still sends RAs when there is no prefix to advertise. That is expected if you advertise DNS. If this is the same issue, then make sure that under IPv6/ND settings DNS advertise is set to no (and any other options). If not, then please open support ticket with the related information included.
RA can advertise also options only, without any prefixes and become a "router" causing default route to be installed. This is how it is supposed to be. Of course, if I am guessing correctly. Having a support ticket would be more efficient.
The issue noted!
Upgraded ATL-5G-R16 to 7.32.2 stable from 7.32.0.
Internet connection is via LTE Passthrough, with local DHCP server attached on APN interface passing Carrier lease (2 minutes duration; it was 1 minute by default) onto downstream WAN firewall interface.
The setup follows: ATL 5G R16 (ATL16) â Passthrough Mode with IPFire & Persistent Management. MikroTik LTE modem in passthrough mode with management access over a VLAN trunk, using IPFire as the firewall. ¡ GitHub
Before the upgrade
After the upgrade
I have now changed the lease to 12:00:00 so I can recover the situation, however this is not desireable given mobile network instability.
In summary, after the upgrade and during lease expiration time the APN IP is now dropped causing connectivity disruption.
Any ideas ?
I'm interested to see what Mikrotik will do about the thousands of LMT LTE18 routers out there that can barely fit the Long Term version r7.20.8-arm + qcom-ac. 7.21.5 with qcom-ac is +110kb
However, the change from >= 7.23 when combined with the fact that by default there is a * /ipv6 nd entry with interface=all and the default value ra-lifetime=30m means that RouterOS by default sends out Router Advertisements message telling everyone that it's a default gateway on every interfaces!
This causes RouterOS devices only acting as switches or access points to also advertise themselves as gateway. RA is also sent out on the WAN interfaces towards the ISP and we have cases on this forum where the ISPs simply block the internet access when they detect rogue RA messages from the client.
This doesn't seems to depend on the DNS setting under the /ipv6 nd entry.
Also I don't understand why this change is needed in 7.23 at all. Because the use case of sending RA with DNS and MTU information even when no prefix should be advertised was already implemented and solved in 7.21 with this change:
We could already since 7.21 have a configuration where for one interface:
/ipv6 nd entry for the interface with interface=the-interface and whatever needed settings/ipv6 nd prefix entry for the interface with:/ipv6 nd prefix
add interface=the-interface prefix=none
And that was enough for RouterOS to send out RA message on that the-interface interface with all needed DNS/MTU/Managed/Other-Flags without an attached IPv6 prefix.
The change in 7.23 is unnecessary! The behaviour in 7.21 where RA is only sent if there is a corresponding /ipv6 nd prefix entry for the interface was perfect and prevent the problem of sending rogue RA by default on all interfaces.
/ipv6 nd prefix entry could be dynamically added by turning on advertise under /ipv6 address, or for cases where no prefix should be advertise, 7.21 already gave the ability to create /ipv6 nd prefix entries with prefix=none.
Please revert to the 7.21 behavior instead of the 7.23 one.
This is already information that Mikrotik did not reveal. You actually have to diff every file inside routeros.npk with previous version. Have fun, as this release does also contain other changes/fixes. But feel free to burn AI tokens and post the results here. 
I can tell what they'll do: ABSOLUTELY NOTHING!
They might tell you to downgrade to "wireless" drivers if qcom-ac is "too much for your hardware", and that hardware was not delivered with "qcom-ac", and that you are installing "qcom-ac" on your own risk, and that they never recommended it in the first place... Anything but the obvious things: split "qcom-ac" in two (RB4011 and others) and FIX THE KERNEL FAILURES.
Instead, they will waste more time on making Winbox4 more unusable than it currently is.
No, See the elaborate reply by @CGGXANNX
From 7.23 the router announces itself as gateway even when the (only) address on the interface is configured as advertise=no. It should not advertise addresses when advertise=no.
The information that it was PPP-related was previously in this thread, as part of the since deleted posts.
When we compare all files under /bndl/ppp then only the binary executable /bndl/ppp/nova/bin/ppp was modified (besides the non-executable files /bndl/ppp/home/web/webfig/ppp.info and /bndl/ppp/nova/lib/console/1090519040.mem).
And using the tool mentioned above, with both the x86 and and ARM64 files, the small code changes can be found (that produce the same decompiled C code for both x86 and ARM64).
That button/banner does not seem to change in real time. Sometimes even changing the update channel does not change it immediately.
This made my day, thank you.
Well, it does change, but for the worse. E.g. you opened Winbox to a router running 7.23.1 some days ago, and now you use system->package->upgrade to upgrade it to 7.23.2, the router reboots and Winbox re-connects but now it shows the "version 7.23.1 available" message.
I suspect that Winbox only checks latest version at startup, instead of when connecting.
Edit: I see a new Winbox 4.2rc2 has been released to resolve this issue.
Also when qcom-ac would be released in a separate RB4011 version (not necessary, lots of storage so it could run the full driver) there should be the possibility to install "wireless" alongside for the 2GHz interface. Without that, qcom driver on RB4011 is useless for the vast majority of users.
Just remarking that after upgrading to 7.23.2 one of my remote devices became unreachable. After investigation it turned out to be an OSPF issue, for some reason 2 out of 3 interfaces are marked as 'duplicate configs'.
I already had seen a similar warning since upgrading to 7.23.0 on my home device, but didnt experience any connectivity issues yet (I guess because I just didnt had traffic on that connection). My config always worked well before 7.23, and there are def. no duplicated router-id's or networks (dbl checked with a llm).
Changing the interface-templates (on both sides) from ptp to broadcast did make it work again. On my home devices it was also weird, I had 3 duplicate configs then I disabled/enabled the ospf instance and I only had 2 duplicate configs.