On 3 September, MikroTik sent an iOS notification titled "Important security update" and released fixes across every RouterOS branch. The message said most configurations were not at risk, but everyone should upgrade.

That got my attention. It did not give me enough information to manage the risk.

What we know

MikroTik released 7.24.2 stable, 7.23.4 long-term, 7.25beta3 development, and 6.49.21 for RouterOS 6.

MikroTik is withholding technical details to give people time to patch. Staff have confirmed that protecting management ports is important. They also said a segmented network with management blocked from unknown sources is not at immediate risk.

We still do not have a CVE, the affected service, vulnerable version range, impact, exploitation status, or indicators of compromise. MikroTik has not said how an operator can tell whether a router was exposed or already compromised. Its security page has no matching advisory as of 4 September.

Forum users have theories about SSH and WinBox. MikroTik has confirmed neither. Guesswork is not an impact assessment.

Why the long-term update worries me

RouterOS 7 long-term users were on 7.21.5. The fix moved them to 7.23.4 instead of providing a narrow update to the existing branch. MikroTik said some fixes were critical and that every hour of delay added exposure.

Operators then reported DHCPv6 failures after installing 7.23.4. Several said 7.24.2 restored service. Another reported losing LTE traffic after the upgrade. These are field reports, not confirmed defects, and other upgrades completed without problems.

The long-term backport appears incomplete. One operator reproduced the DHCPv6 failure by moving between 7.23.4 and 7.24.2, while others reported the same broken prefix acquisition. Shipping an urgent security backport that breaks DHCPv6 is unacceptable. Long-term users should not have to move to the stable channel just to restore IPv6.

The wider quality concern is real. MikroTik's own 7.24.1 changelog fixed a WireGuard problem introduced in 7.24 that could leave a tunnel unusable. It also fixed an RB3011 regression introduced in 7.22. The latest builds fix a certificate trust-store setting broken in 7.22.2.

This is why people use staged rollouts, especially on network equipment. An urgent but unexplained security update forces operators to choose between an unknown security risk and a poorly bounded change risk.

What I would do now

First, block WinBox, SSH, WebFig, API, and other management services from untrusted networks. Check IPv4 and IPv6 input rules, internal VLANs, VPN access, and management VRFs. Do not rely on NAT or /ip service restrictions alone.

Then back up the router and export its configuration off-device. Test the fixed release on representative hardware before a fleet rollout when management is already isolated. Verify PPPoE, DHCPv6, routing, VPNs, Wi-Fi, scripts, and monitoring after the reboot.

If management was exposed, restrict it immediately, preserve logs and configuration, and treat the update as urgent. Clean logs do not prove a router is clean because MikroTik has not published indicators for this issue.

MikroTik was right to issue the notification and ship fixes across supported branches. It can also withhold exploit code while publishing the affected service, exposure conditions, fixed-version matrix, exploitation status, and safe checks for compromise.

Urgency is useful. Operators still need enough information to make a safe decision.