certificate - remove "GoDaddy Class 2 CA" from built-in root certificate authorities store;
console - improve stability;
crypto - improve stability (CVE-2026-67278);
ipsec - fix duplicate connections on IKEv2 retransmissions;
ipsec - improve stability;
leds - fix LEDs set to interface status staying off when the interface is active;
ppp - improve stability;
ptp - add manual configuration of PTP message intervals and per-port enabling and disabling;
ptp - fix PTP offset instability under heavy background multicast traffic;
ptp - fix PTP timestamps showing the wrong time on CRS510;
sfp - improve QSFP-DD breakout link establishing to NVIDIA DGX Spark and other devices;
system - improve stability;
user - improve failed login delay logic (CVE-2026-16347);
wifi - update radio regulatory information;
www - improve stability;
To upgrade, click Check For Updates under System/Packages menu and select the long term Channel in RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download
Everything went smoothly
I encountered an issue after the update (please post about the device, configuration, and unexpected symptoms)
I encountered an issue, but solved it (please post the solution)
0voters
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. The file must be generated while a router is not working as suspected or after some problem has appeared on the device
Please keep this forum topic strictly related to this particular RouterOS release.
==================================================================================================
DOH MONITOR | 16:13:36 | RUNTIME: 8 min | CYCLE: 99/∞
==================================================================================================
Target Type MS Max Med Jit Fail Att % Status Last Err SF TO
--------------------------------------------------------------------------------------------------
Quad9 DoH2 Cold 122 593 119 3 2 99 97% OK TIMEOUT 1 1
Quad9 DoH2 Warm 2 221 3 1 0 99 100% OK NONE 0 0
--------------------------------------------------------------------------------------------------
Cloudflare seems fair enough for me
==================================================================================================
DOH MONITOR | 16:24:45 | RUNTIME: 8 min | CYCLE: 99/∞
==================================================================================================
Target Type MS Max Med Jit Fail Att % Status Last Err SF TO
--------------------------------------------------------------------------------------------------
Cloud DoH2 Cold 25 87 32 7 0 99 100% OK NONE 0 0
Cloud DoH2 Warm 29 29 2 27 0 99 100% OK NONE 0 0
--------------------------------------------------------------------------------------------------
I like that they named the CVE's, Kudos to mikrotik for a step in the right direction. +1,
This helps cut the noise and anxiety when inevitably some critical CVE hits
The fact that this specific CVE is still under embargo makes no difference to me as a user of their software.
And in my view, is generally good practice from the researcher.
It means that they properly communicated with MikroTik before publicizing their work.
So.. just a direct effect of good work by the researchers, and good communication and documentation practices from Mikrotik.
In this scenario the /supportsec blog is a redundancy, because all relevant info (update now, question us later) is already published in the changelogs.
Still, a lot of "improved stability" entries.... but we'll get there when we get there
The referenced CVE is neither new or under embargo, it's just not very interesting and so no one is really tracking or updating it.
The vulnerability is that if the api endpoint is exposed to the attacker, then if additionally the attacker can guess a correct username and password then they can do bad things. Duh.
The "vulnerability" is that the login attempts are not or inconsistently restricted. (And it isn't clear at all how they should be restricted...)
If I am not mistaken, within the established procedures (and perhaps even formal rules—I am not familiar with the details), the vendor is required to maintain a centralized source of information regarding all security vulnerability issues.
I think the only thing not done well was that a 7.21.6 version could also have been released as 7.21.5 + only the critical fixes.
This would have allowed everyone on the then current 7.21.5 lts to upgrade immediately with minimal risk of breakage, and only then upgrade to the new 7.23.x lts at their leisure.
I only propose this sort of treatment for truly critical fixes.
CVEs or other vulnerabilities?
"Instantly."
Okay, okay... It’s not that much of an exaggeration...
But certainly within less than two business days.
And fixes for CVEs released for the specific minor version currently used in the Long Term release.
None of that "bumping the Long Term version to match the Stable version just to avoid releasing a patch for the specific minor release used in the Long Term" nonsense.
(I am referring specifically to that wrong and deplorable move where the Long Term version was shifted from 7.21 to 7.23, thereby forcing a host of radical changes that had occurred between those two minor releases.)
I would suggest that the Long Term version be one or more minor versions behind the Stable version.
E.g., if Stable is currently at 7.24, Long Term should be 7.22 or earlier.
