MikroTik RouterOS: patch fast and schedule automatic updates

Updated November 2026

To patch a MikroTik router, check the installed version, pick a release channel, run /system package update install and then upgrade the RouterBOOT firmware. As of November 2026 the current releases are 7.25 (stable), 7.24.6 (long-term) and 6.49.23 (RouterOS 6). Any older version is missing fixes for flaws that attackers are using now.

7.25stable channel, released 22 October 2026
7.24.6long-term channel, released 30 October 2026
6.49.23RouterOS 6, released 7 October 2026

Why to update now

In September 2026 CERT Polska reported a set of RouterOS flaws, which it calls “MikroTrick”. Two of them let an attacker take full control of a router whose SSH service is reachable, without a password. Attackers used them from at least 2 September 2026 and created a full-rights user called ops. CISA lists three of the flaws as exploited. In October, MikroTik also disclosed a critical flaw in the web interface that lets one request run code as root.

Recent RouterOS flaws and the first fixed versions
CVE	Service	What an attacker can do	Fixed in
CVE-2026-67279	SSH	Run commands without logging in (exploited)	6.49.21, 7.23.4, 7.24.2
CVE-2026-86060	SSH	Crafted username gives full admin rights (exploited)	6.49.21, 7.23.4, 7.24.2
CVE-2026-67276	SSH (v7.9+)	Log in as a user with an RSA key, without the private key	7.23.4, 7.24.2
CVE-2026-67277	Bandwidth test	Leak memory, crash the router (exploited)	6.49.21, 7.23.4, 7.24.2
CVE-2026-67281	WebFig (v7.20+)	Read files, including stored credentials, without login	7.23.4, 7.24.2
CVE-2026-84411	WebFig (www, www-ssl)	Run code as root with one request	6.49.23, 7.23.8, 7.24
CVE-2026-103903	WinBox (v7)	Low-privilege user gets an admin session	7.23.8, 7.24.5

Do not stop at the first fixed version. 7.23.4 and 7.24.2 had an incomplete fix for a related certificate flaw (CVE-2026-67278), and later releases fixed more. Install the newest release of your channel. Details for each issue are under Vulnerabilities.

Check your version

Run these in the terminal (WinBox: New Terminal, or SSH):

/system resource print              # version, architecture-name, board-name
/system package update print        # channel, installed-version, latest-version
/system routerboard print           # current-firmware and upgrade-firmware

The commands on this page use the space-separated form, which works on RouterOS 6 and 7. RouterOS 7 also accepts the slash form, such as /system/package/update/print. Cloud Hosted Router (CHR) and other x86 installs have no /system routerboard menu, so skip the firmware steps there.

Choose a release channel

long-term: Released rarely, critical fixes only. The best choice for most production routers.
stable: New features and fixes every few months. Fine for routers that need newer features.
testing and development: MikroTik says testing should not be used in production. Development is for trying out new features.

/system package update set channel=long-term

RouterOS 6 stays on 6.49.x. To move to RouterOS 7, MikroTik's upgrade guide has you select the “upgrade” channel, which only offers 7.12.1. Install that first, then check again to see newer 7.x releases. Read the upgrade notes before you do this on a remote router.

Update RouterOS now

Save a backup and a readable export first, and copy both files off the router:

/system backup save name=pre-update
/export file=pre-update
/system package update check-for-updates
/system package update print        # status: New version is available
/system package update install      # downloads, installs and REBOOTS

install reboots the router as soon as the download finishes. To download now and reboot later in a quiet hour, use /system package update download and then /system reboot. The router itself must reach upgrade.mikrotik.com on TCP port 443. When it is back, run /system resource print to confirm the new version. If the upgrade failed, look in /log print.

Upgrade the RouterBOOT firmware

RouterOS updates often ship a newer RouterBOOT (the boot loader), but it is not applied by itself. MikroTik strongly recommends upgrading it after every RouterOS update:

/system routerboard print           # compare current-firmware with upgrade-firmware
/system routerboard upgrade
/system reboot                      # REBOOTS again

If you set /system routerboard settings set auto-upgrade=yes, the router upgrades the firmware by itself after a RouterOS update. The new firmware is used only after one more reboot.

Schedule automatic updates

A scheduler entry can check for a new version every night and install it in a maintenance window. The script below handles RouterBOARD firmware too. It needs auto-upgrade=yes, set above:

/system script add name=auto-update source={
    :local fwNow [/system routerboard get current-firmware]
    :local fwNew [/system routerboard get upgrade-firmware]
    :if ($fwNow != $fwNew) do={
        :log warning ("auto-update: RouterBOOT " . $fwNow . " to " . $fwNew . ", rebooting")
        /system reboot
    } else={
        /system package update check-for-updates once
        :delay 15s
        :if ([/system package update get status] = "New version is available") do={
            :log warning ("auto-update: installing RouterOS " . [/system package update get latest-version])
            /system package update install
        }
    }
}
/system scheduler add name=auto-update start-time=03:30:00 interval=1d on-event=auto-update

On the first night with a new release the router installs it and reboots. On the next night it sees the newer firmware and reboots once more to load it. On CHR and x86, leave out the firmware lines and keep only the check-for-updates part. The 15-second delay is there because the check runs in the background. MikroTik's own update-check example waits the same 15 seconds.

What the nightly script does. It reboots at most once per run.

Reboots without asking. Every install drops routing, VPNs and your own remote session for a minute or more. A bad update on a remote site can cut you off. Test the script on a lab router or a non-critical site first. Keep out-of-band access (console, a second link, or someone on site) for routers you cannot afford to lose. Before you enable it, check that current-firmware and upgrade-firmware match. If they still differ after an update, the script reboots every night, so watch the log.

Weekly window. On RouterOS 7.24 and later, a days property limits the run to certain weekdays: /system scheduler add name=auto-update days=sun start-time=03:30:00 on-event=auto-update. With days, leave the interval at 0s; intervals of 1d or more are not supported.
Permissions. A scheduler entry runs with the policies of the user who created it. Create it while logged in as a full-rights user, or the log shows “not enough permissions”.
Clock. Schedules use the router's local time, so keep the clock synchronized with NTP.
Device mode. The scheduler is not available in the home device mode, and entries cannot be created while the router is in the Flagged state.
Notify only. If you would rather install updates yourself, MikroTik's scheduler guide has a script that logs and emails when a new version appears.

Check the result after the first night with /system scheduler print detail (next-run, run-count) and /log print where message~"auto-update". For update schedules on Linux and BSD servers, see Update schedules.

Lock down management access

Most attacks on RouterOS go through management services that are reachable from the internet. Use Safe Mode (Ctrl+X in the terminal) while you change these settings. If your session drops, the changes are undone.

/ip service print
/ip service disable telnet,ftp,www,api      # add www-ssl,api-ssl,ssh if unused
/ip service set winbox available-from=192.0.2.0/24
/ip service set ssh available-from=192.0.2.0/24

Before RouterOS 7.24, available-from is called address. The service still answers on its port and then closes the connection, so also drop the traffic in the firewall input chain. Do this with an address list of your management networks:

/ip firewall address-list add list=mgmt address=192.0.2.0/24 comment="admin LAN"
/ip firewall filter add chain=input protocol=tcp dst-port=22,8291 \
    src-address-list=!mgmt action=drop comment="management only from mgmt" place-before=0

Keep the default firewall rule that drops input not coming from the LAN. For remote work, MikroTik recommends a VPN such as WireGuard rather than open management ports.

Accounts and other services

/user add name=jsmith group=full password="long-unique-passphrase"
# log in as jsmith in a new session, then:
/user disable admin
/user settings set minimum-password-length=12   # RouterOS 7
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/ip neighbor discovery-settings set discover-interface-list=none
/tool bandwidth-server set enabled=no
/ip dns set allow-remote-requests=no         # only if the router is not your LAN's DNS server
/ip proxy set enabled=no
/ip socks set enabled=no

Give each administrator their own account, and give limited staff a custom group, not the built-in read group, which can still reboot the router. Use passwords of at least 12 characters. In a quoted password, put a backslash before $, " and \.

Signs of compromise

After you update, check for changes you did not make, even if nothing looks wrong:

/system device-mode print on RouterOS 7: flagged: yes means the router found signs of unauthorized changes at boot and disabled them. Treat it as compromised.
/user print and /user ssh-keys print: unknown users (such as ops) or keys.
/log print where message~"ssh:-2": the log pattern CERT Polska saw, “user … added by ssh:-2@…”.
/system script print and /system scheduler print: scripts you did not write.
/ip dns print and /ip dns static print: changed DNS servers or static entries.
/ip proxy print, /ip socks print, /ip firewall nat print: proxies or redirects you did not set up.
/interface print and /file print: unknown tunnels or files.

If you find any of these, follow CERT Polska's advice. Isolate the router and save the logs and configuration. Report the incident to your national CSIRT. Reset to factory settings and rebuild from a configuration you trust. Do not restore a full backup from the possibly compromised router. Then change every password, key and secret the router held. Do not clear the Flagged state until the analysis is finished. For the wider incident steps, see Emergency patching.