Post cover image

October 10, 2026

The MikroTik Near-Zero-Day Every MSP Should Study

MikroTik was not the whole story; exposure management was. Here is what MSPs should change before the next zero-day.

By Talal Abbasi

8 min read

When a serious vulnerability affects a platform you deploy across client sites, the first question is not usually, "What is the CVE score?"

It is: "Which of our clients can be reached right now?"

That was the practical problem behind the recent MikroTik RouterOS disclosures. CERT Polska reported evidence of attack activity before the full technical details and coordinated disclosure were published. For defenders, that meant a short window to understand the issue, identify exposed devices and put containment in place.

For an MSP, that is the uncomfortable reality. A vulnerability does not become a major incident simply because it exists. It becomes one when it affects a service you have enabled, on a device that is reachable, in a client environment you support.

What happened with MikroTik

CERT Polska identified and coordinated disclosure for six RouterOS vulnerabilities, later referred to collectively as MikroTrick. The issues affected SSH, the bandwidth-test service, X.509 certificate validation and WebFig.

The most concerning combination involved two SSH flaws.

The first, CVE-2026–67279, related to how RouterOS handled an SSH rekey request. The device entered the connection-protocol stage even though user authentication had not completed. This allowed an unauthenticated client to open a session channel and send commands.

The second, CVE-2026–86060, allowed a specially crafted SSH username to manipulate the RouterOS policy mask. When chained with the first issue, the result was a session with full administrative privileges.

No password. No private key. No completed login.

That is why this was more than another SSH hardening discussion. If SSH was reachable, an attacker had a credible path from network access to complete control of the router.

Were these zero-days?

It depends how strictly you use the term.

MikroTik released fixes on 3 September 2026. CERT Polska published its detailed technical analysis two days later. However, CERT Polska also reported that the earliest publicly available attack logs dated from 2 September, before the fixes were released.

From a defender's perspective, this was not a normal "patch your devices" advisory. Attackers appear to have had a working exploitation path before the wider security community had complete public visibility into the vulnerability, its indicators or the correct response.

None

For most MSPs, MikroTrick should be treated as a near-zero-day event. The important question was no longer only, "Which devices need patching?" It was also, "Which devices may already have been accessed?"

How defenders spotted it

One detail from the CERT Polska analysis is particularly useful for MSPs: the initial exploitation did not necessarily look like a normal failed login.

CERT Polska reconstructed attacker activity using attack logs and reports received during its investigation. Recurring indicators included connections from a specific external IP, an authentication attempt using the username -2, and the creation of a fully privileged account named ops.

That matters because the first sign of compromise may not be a failed authentication alert. It may be what happens afterwards: a new admin account, an unfamiliar SSH key, a scheduled task, a script, a configuration change or unexpected outbound traffic.

Authentication logs alone are not enough for network-device security. You need visibility into the whole management plane.

Start with an exposure review

Before rushing to patch every device, establish which routers actually expose the affected service.

A device running an older RouterOS version may be low risk if SSH, WebFig and API are restricted to a management VLAN. Another device on the same version may be urgent if SSH is reachable from the internet.

Start by checking the RouterOS version and enabled services:

text/system resource print
/system package update print
/ip service print

The first command shows the RouterOS version, board name, uptime and CPU load. The second shows the installed package version and update channel. The third shows which management services are enabled, their ports and any address restrictions.

For a quick overview of services across a device, use:

text/ip service print detail

Pay particular attention to:

  • ssh
  • www
  • www-ssl
  • api
  • api-ssl
  • telnet
  • ftp
  • winbox

Then check whether the device has interfaces or firewall rules that expose those services beyond a trusted management network:

text/ip address print
/ip firewall filter print detail
/ip firewall nat print detail
/ip firewall service-port print

If you manage multiple sites, export the relevant details into your RMM, documentation platform or asset inventory. At minimum, record:

  • Client and site
  • Device identity and role
  • RouterOS version
  • Enabled services
  • Management access path
  • WAN exposure and port forwards
  • VPN endpoints
  • Backup status
  • Whether the device is monitored centrally

This inventory should be queryable. During an incident, you need to answer in minutes, not days: which client routers have SSH enabled and reachable from outside the management network?

Contain exposure before patching

When a serious vulnerability emerges and no fix is available, patching is not the only answer. Sometimes it is not even the first answer.

Reduce what an attacker can reach.

First, identify the services you can safely disable. In many SME deployments, Telnet, FTP and unencrypted API access are unnecessary:

text/ip service disable telnet,ftp,api

If you do not use the plain HTTP WebFig interface, disable it too:

text/ip service disable www

If you use HTTPS WebFig, do not disable it without checking whether engineers, monitoring tools or client staff depend on it. Instead, restrict it to a management subnet or VPN range:

text/ip service set www-ssl address=10.10.99.0/24

Do the same for SSH and API services:

text/ip service set ssh address=10.10.99.0/24
/ip service set api-ssl address=10.10.99.0/24

Replace 10.10.99.0/24 with your actual management subnet or VPN address range. If you use several trusted ranges, RouterOS accepts a comma-separated list:

text/ip service set ssh address=10.10.99.0/24,192.168.100.0/24

If a service is not needed at all, disable it rather than merely restricting it:

text/ip service disable telnet,ftp,www,api,api-ssl

The bandwidth-test service is another common source of unnecessary exposure. Unless a client specifically requires it, disable it:

text/tool bandwidth-server set enabled=no

You can confirm the result with:

text/ip service print
/tool bandwidth-server print

A restricted service should show an Available From address list. A disabled service should show disabled.

Use firewall rules as a second layer

Service address restrictions are useful, but firewall rules provide an additional control layer. They are especially helpful when multiple engineers, monitoring systems or VPN ranges need access.

Create a dedicated address list for approved management sources:

text/ip firewall address-list
add list=MGT-ALLOWED address=10.10.99.0/24 comment="MSP management VLAN"
add list=MGT-ALLOWED address=192.168.100.0/24 comment="MSP VPN range"

Then create rules that allow management traffic only from those sources:

text/ip firewall filter
add chain=input action=accept protocol=tcp dst-port=22 \
    src-address-list=MGT-ALLOWED comment="Allow SSH from MSP management"
add chain=input action=accept protocol=tcp dst-port=443 \
    src-address-list=MGT-ALLOWED comment="Allow HTTPS WebFig from MSP management"
add chain=input action=accept protocol=tcp dst-port=8291 \
    src-address-list=MGT-ALLOWED comment="Allow Winbox from MSP management"

After the allow rules, add explicit drop rules for management traffic from other sources:

text/ip firewall filter
add chain=input action=drop protocol=tcp dst-port=22 \
    comment="Drop SSH from unapproved sources"
add chain=input action=drop protocol=tcp dst-port=443 \
    comment="Drop HTTPS WebFig from unapproved sources"
add chain=input action=drop protocol=tcp dst-port=8291 \
    comment="Drop Winbox from unapproved sources"

Be careful with rule order. RouterOS processes firewall rules from top to bottom. Your allow rules must appear before the corresponding drop rules, otherwise legitimate management access may be blocked.

You can view the active rule order with:

text/ip firewall filter print

If you need to insert a rule at a specific position, use place-before:

text/ip firewall filter add chain=input action=accept protocol=tcp dst-port=22 \
    src-address-list=MGT-ALLOWED place-before=0

That example places the rule at the top of the filter chain. In a production firewall, review the existing rules first; blindly placing a rule at position zero can interfere with established traffic flows.

Patch in order of risk

Not every device needs an emergency upgrade at the same time.

Internet-facing routers, VPN concentrators and devices with exposed management services come first. Then look at devices where SSH, WebFig or API crosses an untrusted network. Internal devices with management access limited to a trusted VLAN can usually follow a normal maintenance process.

Before upgrading a critical device, take a configuration export and binary backup:

text/export file=pre-upgrade-config
/system backup save name=pre-upgrade-backup
/system resource print

The export produces a readable configuration file. The binary backup captures the device configuration in MikroTik's native backup format. Keep both outside the device, ideally in an encrypted MSP documentation or backup repository.

A backup saved only on the router you are about to upgrade is not much of a backup.

Check available updates:

text/system package update check-for-updates

Review the result carefully before installing:

text/system package update print

For a controlled upgrade, download and install the update:

text/system package update download
/system package update install

RouterOS will normally prompt for a reboot after installation. Before rebooting, confirm that the download completed successfully and that you have a restorable backup.

After the reboot, verify the installed version:

text/system resource print
/system package update print

Then confirm that required services are still available and that unwanted services remain disabled:

text/ip service print
/tool bandwidth-server print

Look for signs someone got in

A patch removes the vulnerability. It does not automatically remove an attacker who may already have created persistence.

After patching, review the device carefully.

Start with critical and security-related logs:

text/log print where topics~"critical"
/log print where topics~"error"
/log print where topics~"warning"
/log print where topics~"system,info"

Then review user accounts, SSH keys and active sessions:

text/user print detail
/user ssh-keys print detail
/user active print

Look for accounts you do not recognise, accounts with unnecessary full privileges, unfamiliar public keys and active sessions from unexpected IP addresses.

Check scripts and scheduled tasks:

text/system script print detail
/system scheduler print detail

A new script or scheduler entry can be used to reapply configuration changes, download files or maintain access after a reboot.

Review stored files and recent configuration changes:

text/file print detail
/system history print

Then inspect firewall, NAT, DNS and fetch configuration:

text/ip firewall filter print detail
/ip firewall nat print detail
/ip dns print detail
/tool fetch print detail

Look for unexpected port forwards, DNS servers, static DNS entries, proxy settings or outbound fetch jobs. A compromised router may not announce itself through a failed login. It may quietly change DNS, add a NAT rule or create a scheduled task.

MikroTik has indicated that RouterOS may mark potentially affected devices as "Flagged" in the log. That alone is reason to review logs rather than assume a patched version means the device is clean.

Make this part of the MSP service

Clients rarely want a detailed explanation of every CVE. They want to know that their provider has a plan.

A credible MSP service should include:

  • A maintained inventory of network devices, firmware versions and enabled services.
  • A patch SLA based on exposure and exploitability, not just severity scores.
  • Regular management-access and segmentation reviews.
  • Centralised logging and alerts for configuration change.
  • Verified configuration and binary backups.
  • A documented containment process for unpatched vulnerabilities.
  • A post-incident review and clear client communication.

This turns zero-day readiness from a late-night scramble into a visible, repeatable service.

A balanced view

MikroTik is not unsafe because these vulnerabilities existed. Any platform deployed across enough customer sites will eventually face a serious flaw.

The difference is whether the MSP already knows which routers expose SSH, which clients have management ports reachable from untrusted networks, and how to contain the problem before a patch is available.

In the MikroTrick case, the exploitation path depended on SSH being reachable. That should be reassuring in one sense: access controls still matter. But it is also a warning. A router that is configured well today can become a problem tomorrow if a new flaw turns an exposed service into an entry point.

The MSPs that handle that moment well will not necessarily be the ones with the most impressive security presentation. They will be the ones who already know their estate.

Sources

  • CERT Polska, MikroTrick: technical analysis, disclosure process, and the use of LLM agents, September 2026. cert
  • CERT Polska, Critical vulnerabilities in MikroTik RouterOS are being actively exploited, September 2026. cert
  • NIST National Vulnerability Database, CVE-2026–67279.
  • Cloud Security Alliance, MikroTrick: Chained MikroTik RouterOS Flaws Bypass SSH, September 2026. labs.cloudsecurityalliance
  • MikroTik, September 2026 vulnerability, MikroTik Security Advisory.