Security

Advisories from NVD

Once a day the manager pulls the MikroTik RouterOS slice of the NVD feed and matches every record's affected version ranges against the RouterOS version each device reported at its last poll. Nothing is stored per device — the feed is kept once and the matching is done on the fly.

The version string is the whole of the key. Nothing else about a device takes part in the match: not the board, not the architecture, not which packages are installed or which services are switched on. A record that in practice only bites one model, or only a router with a particular service exposed, is still shown against every device on an affected version. And a device the manager has never polled has no version recorded, so it is matched against nothing at all and does not appear in the counts — an empty row on this page is not a clean one.

One class of record is deliberately never matched: an advisory whose affected range is an open wildcard — "all versions", with no bound at either end. NVD uses that freely on decades-old entries, and honouring it would flag every router you own against every one of them. It is a trade, and it is stated here because it cuts both ways: a wildcard record that genuinely does affect current RouterOS will not be shown either. The same goes for a record whose bounds are not RouterOS version numbers at all — NVD sometimes writes a calendar date where a version belongs, and those are dropped rather than guessed at.

It is informational, always. A matched advisory never blocks an upgrade, a command or anything else; it changes what you see, not what you can do.

The same roll-up feeds three other places, so you do not have to open this page to notice: a banner on the dashboard when High or Critical advisories affect at least one device, a badge on the device cards, and a Security Advisories card on the device's own page. All four are scoped — a user limited to some sites sees only the devices in them. On the device's own card the advisory list and the vendor-patch line from the next section share one panel, still labelled as the two different claims they are.

The honest limit is coverage. MikroTik's presence in NVD is patchy: plenty of real RouterOS issues are fixed with a line in a changelog and never receive a CVE number at all. An empty first tab means "nothing in NVD matches", not "you are safe" — which is exactly why there is a second tab.

Vendor patches

The second tab reads MikroTik's own release changelogs and asks a narrower question: has a security release shipped on the branch this device runs, and is the device below it?

That is a weaker claim than a CVE match, and the two are deliberately never merged. A CVE record states the versions that are affected. A changelog states only the version that fixes something — it never says which versions were vulnerable. Merging the two would mean inventing an affected range, so the tabs stay separate and say different things.

Only branches actually present in your fleet are fetched. MikroTik publishes no index of releases, so each branch is probed by version number — 7.23, then 7.23.1, 7.23.2 and so on up to twenty patch releases, stopping after three consecutive misses. A branch nobody runs is never fetched, so this tab is not a place to look up a release you have not deployed. Security-relevant lines are those MikroTik itself marked with !), plus any line naming a CVE or using the words security or vulnerability, plus any security notice written as free text above the change list.

That last case is not a detail. The releases of 3 September 2026 — 7.24.2, 7.23.4 and 6.49.21 — carry their warning as a plain sentence above the list, with no marker, no CVE and no entry mentioning security anywhere in the change list. A reader who only looked at marked lines would conclude those releases fixed nothing of the sort.

Comparison stays inside the device's own branch. MikroTik routinely fixes one issue across several branches at once and the changelog never states which other branches were affected, so the manager does not guess on your behalf.

Why the text is snapshotted

The first time a release's security lines are seen they are saved verbatim, and re-checked on the same schedule as the CVE feed afterwards. If MikroTik edits the text after publication, the tab shows the release under "changelog edited upstream", with the removed lines under one heading and the replacement lines under the next.

This is not hypothetical. RouterOS 7.23.2 shipped with the line !) ppp - fixed CVE-2026-59108;, which was later replaced with vaguer wording — and that CVE identifier appears in no public registry. Whatever was published first is what the manager keeps.

The snapshot can only hold what your own install saw. A release that MikroTik published and edited before this install first read it is snapshotted in its edited form, and that edit is undetectable here.

Auto-block

The third tab watches the syslog stream for hostile behaviour and can push the source address into a firewall address-list across the whole fleet. It is off by default, and it does nothing at all until your routers are sending logs to the manager — see the Logs page, which is the prerequisite, not an optional extra.

Everything that reaches the syslog port is read for signals. That is independent of which devices receive blocks: a line counts whether or not its device is opted in, and whether or not the manager could work out which device sent it.

What counts as a signal

Both kinds feed the same counter. Attempts are aggregated per source address across every device in the fleet, in a sliding window — five attempts within ten minutes by default. An address that hits the threshold becomes a candidate; a slow scan spread over several routers looks, and is treated, like a slow brute-force against one.

That running count is held in memory. Restarting the manager clears every partial count, so an address part-way to the threshold starts again from nothing — candidates and blocks already recorded are unaffected.

RouterOS emits the same failure line whether the username was wrong or only the password was, so the manager treats every login failure equally. Denied connects are noisier by nature, which is why they are opt-in.

Two modes

Audit is the default: candidates are listed with their attempt counts, and an administrator blocks by hand. Auto-block blocks at the threshold without asking. The switch is the "Auto-block" setting; everything else about the two modes is identical.

Reading the candidate, blocked and whitelist tabs is open to every role. Blocking, unblocking and editing the whitelist are administrator actions, as are the settings that govern them and the per-device opt-in on the device form.

A hostile address belongs to no site — it hit the fleet — so the rows themselves are the same for everyone. The device column is not: a user limited to certain sites sees the reporting device's name only when that device is one of theirs, and a dash otherwise. (v1.94.0+)

What a block actually does

Blocking adds one address-list entry per opted-in device, with RouterOS's own timeout so the entry expires on the router itself:

/ip firewall address-list add list=mikr-blocklist address=<IP> timeout=259200s comment=mikr-ids

That is the whole of it. The manager maintains the list and nothing else — it never creates, edits or reorders a firewall rule. The drop rule is yours to add, once per device, and until you do, a blocked address is listed and still gets through:

/ip firewall raw add chain=prerouting src-address-list=mikr-blocklist action=drop comment="mikr-ids"

If you change the address-list name in Settings, the drop rule has to reference the new name. The default is mikr-blocklist. Entries already sitting on your routers under the old name are not renamed and not withdrawn; they run out on their own timeout.

Entries go only to devices whose "Auto-block (IDS)" field is set to Yes on the device form — off for every device until you set it. A device that is offline when a block is issued has the entry recorded as pending and pushed the next time the manager sees it come online, with whatever remains of the original timeout. A device that was online and refused the command is recorded as failed instead, and that one is not retried.

What expires

Two clocks, and they keep together. The address-list entry expires on each router by itself when the block duration is up — seventy-two hours by default. The manager clears its own record on the same schedule, within five minutes of the entry running out, and the address leaves the Blocked tab on its own. From that moment it is counted like any other address again, so an attacker who comes back is caught a second time. (v1.94.0+)

Unblock ends a block early. It removes the entry from every opted-in device reachable at that moment; devices that are unreachable keep theirs until the router's own timeout runs out. After an unblock — or after an expiry — the address starts accumulating attempts again from zero.

The whitelist

Private ranges are excluded by default, so only public addresses are ever blocked; that behaviour is a setting you can turn off. The set is 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and loopback on IPv4, and loopback, ULA and link-local on IPv6. IPv4 link-local, 169.254.0.0/16, is not in it.

Loopback is always excluded, and so are the manager's own interface addresses. In a container those are the container's addresses, not the address your routers reach the manager on — a bridged Docker install therefore still wants that address in the whitelist by hand. If your manager sits on a private range and "Never block private IPs" is on, which is the default, it is covered by that rule already.

Beyond that, the Whitelist tab takes CIDRs or single addresses by hand: your admin network, a monitoring host, an office range that occasionally fat-fingers a password. Both families are matched as prefixes, so 10.0.0.0/8 and 2001:db8::/32 both do what they read as. (v1.94.0+ for IPv6 prefixes; before that a v6 entry had to be a single address.) An entry that could never match — a malformed address, a prefix length out of range — is refused when you add it, with the reason, instead of being stored.

A whitelisted address never becomes a candidate in the first place. It does not stop an administrator blocking that address by hand, which is not checked against the list.

Switching auto-block on

1. Get logs flowing. Configure the routers to send syslog to the manager and confirm entries are arriving with the right device names attached. Nothing below works without this.
2. Enable the feature. Settings, Auto-block / IDS section: turn Enabled on. Leave Auto-block off for now — audit mode first. Both are administrator settings.
3. Whitelist yourself. Add your management ranges on the Whitelist tab before anything can be blocked, the manager's own address among them, and check that "Never block private IPs" matches how you reach the routers.
4. Opt devices in. Set "Auto-block (IDS)" to Yes on the devices that should receive the list. The bulk-edit action on the Devices page can do this for a selection in one go; either way it is an administrator action.
5. Add the drop rule. One rule per device, referencing the address-list. A template on the Command Templates page is a convenient way to push the same rule to every router.
6. Watch, then arm. Let audit mode run for a few days and read the candidate list. If the addresses it names are the ones you would have blocked yourself, turn Auto-block on.

Thresholds, the window, the block duration, the address-list name and both whitelist behaviours all take effect immediately — none of them needs a restart.

GeoIP rules

The GeoIP generator builds a RouterOS script that fills an address-list from country zone files and installs firewall rules against it. It lives on the Command Templates page, where the Security page links to it, and it is available to administrators.

Generating a rule creates a Script-type template in the Security category. It does not touch a router. Installing it is a separate, deliberate step — the template's Deploy button puts the script into /system/script on the devices you select, and does not run it; you run it from the router, or with a scheduler. Generating is an administrator action; deploying is open to operators as well.

No address is ever looked up here. The manager holds no country data and resolves nothing: it writes a script, and the router itself downloads the country zones when the script runs. Everything below happens on the router, which therefore needs its own route out to the internet.

The two modes

Blocklist drops traffic matching the countries you selected. You choose the direction — inbound, outbound or both — and the chain: raw/prerouting is the default and the cheapest, because it matches before connection tracking, while filter works on input, forward and output. Including the outbound direction adds an output rule in either chain.

Allowlist inverts it: everything whose source is not in the selected countries is dropped. This mode forces the filter chain, because connection state is not available in raw, and the direction and chain choices above are ignored. It also builds in three safeguards, because an allowlist is how people lock themselves out of a router:

• established, related and untracked connections are accepted first, so your current session survives the rule that lands after it. This one is a tick-box, on by default — clearing it is the one way to lose the safeguard
• private ranges, plus any addresses you list under "always allow", go into a second address-list that is accepted before the drop. That set is wider than the auto-block whitelist's: it adds carrier-grade NAT and link-local space on IPv4, and multicast on IPv6
• if the country list came out empty — a failed download, a mistyped country — the drop rule is not installed at all and the script logs a warning instead. Failing open is the deliberate choice: src-address-list=!list against an empty list matches every source on earth

What the script does on the router

Address data comes from the aggregated country zones published by ipdeny.com — IPv4 by default, with IPv6 as a separate set of zones you can add. Every run first removes its own rules and address-list entries, matched by the geoip-mikr comment, then rebuilds them, so re-running never duplicates anything. It clears the chain it is about to write, so a generated rule moved from raw to filter leaves the old chain's rules in place until you remove them yourself.

The zones are fetched over HTTPS without checking the server's certificate, because a RouterBOARD generally carries no certificate store of its own and the fetch would otherwise fail on every board.

The download is done in 64 000-byte HTTP range windows concatenated into a single script variable. That is not premature cleverness; it is the only shape that works. On RouterOS 7.22.1, /file get contents returns nothing at all for files over roughly 50 KB, and a single /tool fetch … as-value is capped at 64 512 bytes — China's aggregated zone is 85 536 bytes, so one fetch silently yielded 4 149 of its 5 504 prefixes. Chunked and reassembled, the same list loads complete in about four and a half seconds.

The optional weekly refresh adds a scheduler entry on the device that re-runs the script by name. It uses the name offered by the Deploy dialogue, so if you rename the script on the way in, edit selfName in the script body to match. The scheduler entry is only cleared and rewritten while that option is on, so turning it off and re-deploying leaves the old entry running.

Before you deploy one

• The account the script runs as needs read, write and test permissions — test is what /tool fetch requires. The weekly scheduler entry it creates is written with ftp in its policy list as well.
• Large countries mean tens of thousands of prefixes. On a low-RAM RouterBOARD that is a real cost; check the model before pointing it at CN, US or RU.
• Country-level address data is approximate by nature, and the manager passes on whatever ipdeny.com publishes without second-guessing it.