Still it makes one think why https://mikrotik.com/supportsec has not had any updates for almost a year already. There was another "panic-release-day" in July and that has no mentions anywhere either.
Have they fired people who maintained that part of their homepage? 
I remember when Fortinet had serious SSL-VPN bug and how their servers were overwhelmed when update came out.
It took us hours of repeated attempts from 2 countries (situation was as bad from both countries obviously) to get that 88 MB of firmware update downloaded. This here was not so bad after all.
This is strange, I have multiple ROS7 devices inc several RB5009's which all run PPPoE over a VLAN to the ONT for internet. All of these are fine running 7.24.2.
See if theres anything in the logs which may shead some light.
See: https://download.mikrotik.com/routeros/7.24/CHANGELOG
*) system - renamed "factory-software" to "minimum-version" and "factory-firmware" to "minimum-firmware";
So those aren't minimum requirements at all, just factory values your device was manufactured with, renamed in 7.24 with somewhat confusing names.
Me too, several routes with PPPoE client. However, in the past I had a script that disabled the PPPoE interface for 5 minutes whenever it went down, otherwise it would often fail to re-establish. It seems to have been fixed here, but who knows how it is in other places.
They are minimum versions in the sense You can't downgrade pass them, not in the sense they are the first version to support this hardware model.
Personally, I liked "factory-version" better.
I haven't personally experenced this myself and iv'e had a lot of Mikrotik gear over the years, guess iv'e been lucky.
Are you using bridge setup? try disable the hw. offload, if you are using it
any update regarding furthur
Hello. I Think was some wrong with DHCP Client v6 (or all IPv6).
I can't receive prefix, address or something else witch DHCPv6 Client, in pppoe or ethernet interface
On 7.23.4:
But in 7.24.2, i recevei the prefix with the same configs:
This screenshots i's from a lab with IPv6. But if emulation is a problem, i have a physical device with the same problem (and some friend with the exactly same problem in devices).
Someone with the same problem?
The update to rb5009, cAPax, wAPax and LtAP mini worked very well. I only had to tweak a script on the LtAP.
It changed from
/interface lte monitor $lteID once do={:set LteInfoNOW $"access-technology"}
to
/interface lte monitor $lteID once do={:set LteInfoNOW $"data-class"}
See:
"factory-version" could be bumped up/down on some devices using universal package.. so this "factory" version could be in fact updated elsewhere (outside of factory) 
See https://manual.mikrotik.com/docs/hardware/routerboard/#routeros-v7--upgrade-steps
Right, I understand now. I hadn't read everything when I first posted, but I think I can provide more details about the issue. I believe it’s a version-related issue, as the same configuration works on versions prior to or later than 7.23.4.
So, we need a permanent fix for this now.
Just a reminder: the problem occurred on the PPPoE and Ethernet interfaces.
After 5 days of 7.24.1 upgrading my RB5009 the device mode got flagged:
mode: advanced
allowed-versions: 7.13+,6.49.8+
flagged: **yes** [emphasis mine]
flagging-enabled: yes
scheduler: yes
socks: yes
fetch: yes
pptp: yes
l2tp: yes
bandwidth-test: yes
traffic-gen: no
sniffer: yes
ipsec: yes
romon: yes
proxy: yes
hotspot: yes
smb: yes
email: yes
zerotier: yes
container: yes
install-any-version: no
partitions: no
routerboard: no
attempt-count: 0
My pihole container did not start and the container configuration was empty. The configuration was flagged with something malicious.
I checked /user and saw a disabled ops user which I did not create so deleted it.
Then I set the flagged=no and hit the reset.
The container config is empty but when I try to re-add it I get the root directory exists:
> /container> add check-certificate=no envlists=ENV_PIHOLE healthcheck-status=\
> \... "good, output: 127.0.0.1\
> "\... \n" interface=veth1 layer-dir="" logging=yes mountlists=\
> \... MOUNT_PIHOLE_PIHOLE,MOUNT_PIHOLE_DNSMASQD name=pihole remote-image=\
> \... pihole/pihole root-dir=/usb1/images/pihole start-on-boot=yes tmpfs=\
> \... /tmp:64.0MiB:01777 workdir=/
> failure: root-dir /usb1/images/pihole already exists
The container mounts and Env settings exist. So this is weird. Perhaps something got exploited between 7.23.1 and now. Not good.
edited to add: I deleted the root folder and redid the container configuration. The package repulled extracted and started fine.
My hAP AX3 upgraded just fine and its container came right back.
Use netinstall... The infection can still present...
And also change password everywhere and check all devices...
deleted
@drotz what versions did you upgrade from (to 7.24.2)?
That‘s the security issues, which mikrotik is not communicating at the moment.
Attacker can create a user with full rights without the need of any access to existing user. Only open admin ports are required.
update looks for it and flaggs the installation if user exists. Mostly all instances with open admin ports are already infected. Just look for the user ops if present.
You should inspect all config for stuff you do not recognize, or if possible, even do a reset. Hard to say what unrecognized user has done in your device.