RouterOS version 6.49.18 has been promoted to long-term.

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

Both the "stable" and "long-term" channels will display that a new version is available, it is the same version.
Should you upgrade if you are already using 6.49.18 "stable"? The 6.49.18 "long-term" does not include any updates apart for a new build time, and discovery packets now use the "long-term" label.

What's new in 6.49.18 (2025-Feb-27 17:58):

*) console - updated copyright notice;
*) fetch - improved system stability when using TFTP;
*) hotspot - properly escape all reserved URI characters;
*) radius - added "require-message-auth" option that requires "Message-Authenticator" in received Access-Accept/Challenge/Reject messages;
*) radius - include "Message-Authenticator" in any RADIUS communication messages besides accounting for all services;
*) system - added "shutdown" parameter for reset-configuration (CLI only);
*) system - fixed false log message about successful package installation;
*) system - fixed v6 to v7 upgrade from separate packages;
*) system - improved system stability;
*) system - set flash-boot mode as "boot-device" after system reset initiated by reset button ("/system routerboard upgrade" required);
*) system - set flash-boot mode as "boot-device" after system reset initiated from software;
*) user - improved authentication procedure when RADIUS is not used;
*) wireless - allow to set Canada2 country profile when locked with US lock package for CubeG device;
*) wireless - fixed antenna gain for SXT5ac device;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. 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.

Nice with a 6.x update, but why is it not Long Term?
Latest Long Term 6.49.13 released 5 May 2024, and no Long Term for 7.x

I am not sure how to explain this mix of Stable and Long Term:

*) system - improved system stability;

Hey @normis and @EdPa, I bet no customer of MikroTik would be upset if you assume some compromise in bringing minimal references of what is being done on release notes.

Hey @EdPa... I'm here to make the same request I made in the v7.17 thread.
If you could provide a little more detail on what kind of improvements, I believe users will be less concerned.

why is it not Long Term?

Maybe a good idea would be if they waited about 3 weeks, and if no monstrous bugs appeared, then they could define that this same version 6.49.18, in addition to being Stable, will also become Long-Term.
As a sign of v6's end-of-life.

Thank You MikroTik Team - that you are working on 6.x ROS version. It's very important to have support for older RouterBoards, and you do. Thank You.

Publishing a new version right away as long-term would beat the purpose of the long-term. As always - if a stable version is "okay", then after a while it is re-published as long-term.

As always - if a stable version is "okay", then after a while it is re-published as long-term.

How long is "after a while"? Last long-term is 6.49.13. Previous stable was 6.49.17, released on 2024-08-07 ... which is quite a bit longer than half a year ago. Are you saying that half a year is not long enough to assess whether 6.49.17 is fit to be long-term? Or are there some bugs in it which make it unsuitable for long-term? If so, can you highlight changelog entry (for 6.49.18) which fixes the "show stopping bug"? (my impression when reading 6.49.18 change log is that only entry, which might excuse the whole ordeal, is *) system - improved system stability; ... which, as quite often with changelog entries, doesn't tell anything in particular).

And it seems that you're saying that none of versions 6.49.14-6.49.17 brought enough of improvement to replace 6.49.13 as longterm version. Me, reading changelogs, can find quite a few entries which warrant replacing 6.49.13 with newer as longterm:
6.49.14: *) smb - improved service stability when receiving bogus packets;
6.49.15: *) system - improved system stability for RBSXTsq5nD;
6.49.17: *) system - fixed an issue with duplicated package list when upgrading from separated to bundled package;
6.49.17: *) system - improved system stability for RBLDF-5nD;

Publishing a new version right away as long-term would beat the purpose of the long-term. As always - if a stable version is "okay", then after a while it is re-published as long-term.

That's because "long term" is meant to refer to an update channel rather than an individual version. Long term does not mean "old". A long term channel should be supported in the long term with bug and security fixes, but not introduce any new features. If you identify a critical issue in a long term version, you will of course release a new long time version asap. "Stable" is normally the default channel, which does get new features and, as the name implies, is stable thanks to sufficient testing. Mixing stable and long term is what defeats the purpose of having distribution channels.

Publishing a new version right away as long-term would beat the purpose of the long-term.

😍🙏🙇‍♂️

As always

In light of a history that I have been following for about 8 years (trying to understand MikroTik world, having come from hardware-based world), I say that using "as always", is pushing the limits of the interpretation of "always" a little.
But if the intention is good, I gladly accept it!

if a stable version is "okay", then after a while it is re-published as long-term.

Please do this! The v6 widows need to understand that it is time to abandon the legacy.

Not having the entire possible mass of MikroTik customers and equipments operating on v7 reduces the volume of samples and the quality of issues to be reported to developers.
In addition to reducing the workforce on the current version, where the most senior guys probably need to be moved to look at the legacy.

I prefer to stay on version 6, where I don't need to report issues in the first place.

I prefer to stay on version 6, where I don't need to report issues in the first place.

This happens because you already know which features don't work, which scenarios will cause problems when used.

When certain types of problems appear you don't even try to solve them anymore because you are already sure that those problemas are due to limitations in the RouterOS software (but knowing is not the MikroTik hardware) and you know it's not worth trying again, opting to just stack another 1036 on the CCR breakwater.

Looking like a comforted widow who has already gone through denial, anger, bargaining, depression... and is now accepting it.

• No! Not supporting multiple types and ALGs, or NAT PMP is not normal!
• No! Not supporting hardware off-load when the silicon supports it is not normal!
• No! Not supporting basic features in IPv6, Radius, or even things like RPKI is not normal!

*) wireless - fixed antenna gain for SXT5ac device;

What does that exactly mean?

Upgarded one of our core-router, a CCR1072 and it got stuck in "rebooting" (LCD).
The only option was to go on-site, remove power, re-power and it booted up (after reboot still with the old version 6.49.17).

After another Upgrade-attempt, it rebooted normally and had 6.49.18. Another reboot (firmware) was uneventful too.
But still strange, never saw such a device stuck in "rebooting"... Not long-term for me!!

*) system - fixed v6 to v7 upgrade from separate packages;

HAP AC2

uptime: 1m35s
version: 6.49.13 (long-term)
build-time: Apr/04/2024 09:57:52
factory-software: 6.44
free-memory: 80.3MiB
total-memory: 128.0MiB
cpu: ARMv7
cpu-count: 4
cpu-frequency: 488MHz
cpu-load: 1%
free-hdd-space: 2660.0KiB
total-hdd-space: 15.3MiB
write-sect-since-reboot: 956
write-sect-total: 16613822
bad-blocks: 0%
architecture-name: arm
board-name: hAP ac^2
platform: MikroTik


Didnt work
insufficent space for upgrade
I had separate package installed.

Did you try netinstall

Did you try netinstall

No point in netinstalling when trying to verify the changelog entry quoted by @Maggiore81

The question is different: does uninstalling one of packages (and thus freeing a few 100kB) allow to upgrade or not?

I usually uninstall all the packages except dhcp/system/security and then I can upgrade to v7. But When I have the combined package, we have more or less the same free space, and the system will upgrade!

Another way is to remove almost all packages the put the combined v6 package. With that I can upgrade to v7 with no issues.

When I did have problem with upgrading 6.x devices due to space problem, I did find an older RouterOS that was smaller than the one I have currently running and downgraded to it. This gave me extra space and I was able to upgrade the device.

You still forgot my #[SUP-126246]: Winbox IPv6 ND reachable time units. First reported in 6.49.10, August 2023. Cosmetic bug (Winbox and Webfig only show wrong units label "ms" instead of "s", value specified in seconds works correctly), but introduced in 6.47.10 which itself was a long-term release.

Did I forget what?

Hummm... Looks like CVE-2024-54772 affects this version also...

Seems that it's not 6.49.18 that will become next long-term.

Seems that it's not 6.49.18 that will become next long-term.

I do not understand why this prevents it from become long term.
Who is so stupid that they do not limit Winbox access? Or even worse have Winbox open to the internet.
Default rules prevent internett from accessing Winbox.

CVE-2024-54772 is fixed by - *) user - improved authentication procedure when RADIUS is not used;

In any case, by default RouterOS does not have this "problem" which yes, can make it "easier" to find the username, but the password?

It's always the users who configure things haphazardly.

CVE-2024-54772 is fixed by - *) user - improved authentication procedure when RADIUS is not used;

That's quite concerning. This CVE isn't even listed in the MikroTik security notices: https://cdn.mikrotik.com/web-assets/supportsec/rss.xml. Nor is it mentioned here: https://mikrotik.com/supportsec.

It's legitimate to quietly patch a vulnerability and include it as a regular changelog item - as long as the issue isn't publicly known. However, the moment a CVE and an exploit are publicly documented, all relevant information must be transparently disclosed.

I'm running 6.49.13 [long-term], should I upgrade the firmware to 6.49.18 [stable] now or should I wait until 6.49.xx [long-term] becomes available?

You allow everyone on the world to try to connect to your RouterBOARD?

@infabo makes an excellent point.
Complete and diligent CVE follow through is critical for maintaining confidence in MikroTik security management process.

Did I forget what?

Sorry if it wasn't clear - MikroTik forgot, not you.
No big issue, but accidentally introduced in a long-term release and now seems impossible to revert in many stable releases.

CVE-2024-54772 (MikroTik-RouterOS Username Enum)
This repo contains the exploit for CVE-2024-54772 which can enumerate valid usernames in Mikrotik routers running RouterOS v6.43 through v7.17.2. The patch is present in v6.49.18 and it will be available in branch v7.18 but it's now still under testing (as v7.18beta2) and will be released in the near future.

Brute force dictionary attack is the correct term, not "Username Enume" which is totally wrong in this context. Also, access to port 8291 is required and additional dictionary attacks for the password, which will be very tricky if there's a delay between attempts.

This is a stupid vulnerability, because surely whoever stupid leaves port 8291 open to the world, is the same one who continues to have "admin" as a username...

And it's also a stupid vulnerability, because the intelligent administrator, if forced for extreme reasons to leave the winbox port open, after having randomly guessed the port knocking, at the third mistake blocks the service (not the attacker's IP, but the service itself) for 10 minutes and warns via sms/mail/whatsapp, so between 3 users "tested in the dictionary" and 3 others months pass...

stupid vulnerability

I agree that it may seem like a "stupid vulnerability".
But it is still a vulnerability.

As far as I know, there are no rules like: "If the vulnerability is silly, it does not need to be fixed."

The patch is present in v6.49.18

However, the moment a CVE and an exploit are publicly documented, all relevant information must be transparently disclosed.

And, if they really fixed the vulnerability after being notified and did not mention it in the release notes, this shows extreme bad faith on MikroTik's part.

This is not the attitude of someone who takes security seriously.

To make the product safer, just don't give it to i–s.
So you need to get a certification and a gun router license.

Hope the CVE fix makes it to long term branch.
Have had the security team ping me multiple times during the last week asking when we are patching this.

Why, do you keep a door open with winbox to the rest of the world?
How could this possibly bother you or the security team?
Do you use the default user admin or some other trivial username???

In another topic it has already come out that if you put the user like "#7464.myXomRuser" it takes centuries of brute force to find it...

Your password username will be bruteforced with an average home computer in approximately...
10000+ centuries

You can find the Answer to the Ultimate Question of Life, the Universe, and Everything in that time.

You can even find supercomputers that are there just for you, but the response speed of the RouterBOARD is not infinite...

Some CVEs are just there to highlight stupid security practices that are being practiced(*), or even those that are not being practiced.

(*) user admin with open port without even changing the port number....

The question is deeper: How come they are able to brute-force the username?

And finally, then they have to find the password...

RouterOS version 6.49.18 has been promoted to long-term.

Both the "stable" and "long-term" channels will display that a new version is available, it is the same version.

Should you upgrade if you are already using 6.49.18 "stable"? The 6.49.18 "long-term" does not include any updates apart for a new build time, and discovery packets now use the "long-term" label.

Thanks for the clarification.

Thank you for the update.

After doing this upgrade, webfig login stopped working for me over https in Firefox ESR.The login form is still displayed but attempting to log in causes the error message "ERROR: Not Found" to show up below the login form.

The webfig login still works over regular http in Firefox ESR and it also works over https in Chrome. Before the upgrade, it worked over https from Firefox ESR too (that's how I did the upgrade). It may also be worth mentioning that I use a non-standard port (i.e., not 443) for the https interface, in case the probem is related to that.

Busy patching in lab. No issues discovered thus far.

Uh, again... This breaks checksums for those that recorded them for the package files.

You should consider dropping the channel string from builds and push the exact same build without rebuild to long-term.

V6.49.18 on RB2011UiAS-2HnD mipsbe

I have a strange problem, and I think it started with 6.49.13. I've noticed that a stable IPSEC connection (only one at all) that's been around for 8 years is suddenly causing problems, and there are always short-term disconnections. Under IPSEC installed-sa, I found over 6,800 entries with current-bytes=0 , addtime=empty and expired-in=00:00:00 . Where do these come from, and how can I flush them using a script without losing the active connect ? DPD is set to 60s 5 retrys. In the list src+dest address are only the same 2 IP´s which are correct for the connection.

Example when it starts happen after a complete flush :

/ip ipsec installed-sa print

0 E spi=0x9C82F33 src-address=18.59.52.10 dst-address=72.78.72.1 state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=256 auth-key="1afb26666315226bfda5371b2be8a01"
enc-key="1efcc46999fd3566565665ffcb1138373b09aa1da6" add-lifetime=6h24m/8h
replay=128

/ip ipsec installed-sa> /ip ipsec installed-sa print where current-bytes=0
Flags: H - hw-aead, A - AH, E - ESP

Nothing is found.

With /ip ipsec installed-sa flush, I also delete the active connection.

set Route Comment is not working properly as it should, when you set the "Action" to accept it will show the route comment when you set it to reject it will show the comment and it appears to work correctly but when you re-login to winbox the comment will disappear again just like with the screenshot below, the comment is gone

https://help.mikrotik.com/servicedesk/s ... SUP-185895

I got a deprecation type of response from mrz on this ticket so it won't moved forward I just wonder why there are still some fixes being push through if v6 is totally deprecated, I could understand if recent code drop to v6 is purely security issue related fix which is not. I'm not questioning their decision but makes me wonder, set comment though not critical but very essential on documenting things and should be bug free in the first place, c'est la vie

Since 6.49.18 I have the problem that the 5GHz WLAN on my RB4011igs becomes extremely slow after 10-14 days of operation. I suspected Capsman and switched to local forward, unfortunately the same phenomenon. Does anyone have similar problems? After briefly deactivating and then activating the 5GHz radio, everything works again ¯\_(ツ)_/¯

Since 6.49.18 I have the problem that the 5GHz WLAN on my RB4011igs becomes extremely slow after 10-14 days of operation. I suspected Capsman and switched to local forward, unfortunately the same phenomenon. Does anyone have similar problems? After briefly deactivating and then activating the 5GHz radio, everything works again ¯\_(ツ)_/¯

It would be useful to configure a reselect interval (CAPsMAN Only), I use 3 hours for 5GHz and 3 hours and 7 minutes for 2.4GHz, in this manner the reselects should not overlap, this way you avoid channel congestion, which is, I believe, what you are experiencing.