MikroTik shipped that port closed: the flaw is theirs, the exception is yours

Since at least 2 September, someone has been logging into MikroTik routers without knowing the password. There has been a patch since the 3rd and a public advisory since the 5th. But the sentence that says the most about this whole business was not written by CERT Polska: MikroTik wrote it, and it is not about the flaw. It is about a but.

The full sentence is this one: "MikroTik default configuration blocks this port from the internet by default, but if you have manually opened this port…". The factory configuration closes SSH towards the internet. The rest of the vendor's paragraph is what to do if somebody opened it by hand.

On some particular day, somebody on your team — or at the company that ran this before you — typed a rule. That rule is what this article is about. The CVE is just the occasion.

What happened, with dates

On 5 September 2026 CERT Polska published the coordinated disclosure of six RouterOS vulnerabilities. It details three of them, and the first two are the ones that matter:

• CVE-2026-67276 (CVSS 9.2), "SSH authentication bypass": RouterOS was not properly verifying RSA public keys during SSH authentication.
• CVE-2026-86060 (CVSS 9.2), "SSH session privilege manipulation via a crafted username": RouterOS "did not properly handle usernames beginning with a disallowed character", and a crafted username escalated privilege.
• CVE-2026-67277 (CVSS 8.8), "memory disclosure and crash via bandwidth-test": unauthenticated access to privileged state, with memory leakage and device crash.

The first two chain together, and the chain has a name: MikroTrick. Combined, in the CERT's own words, it "allows an attacker to take full control of the device without authentication if the device supports remote access using the SSH protocol". No credentials, no username, nothing: reaching the port is enough.

MikroTik shipped the fixed builds on 3 September: 7.25beta3, 7.24.2, 7.23.4 and 6.49.21, four builds spread across four version lines. That day the vendor said two things and deliberately withheld a third: "This is an important security update. Most configurations are not at risk, but upgrading is highly recommended" and, right after, "To give time to update your systems, we are not currently publishing detailed information". The detail arrived on the 5th, with CERT Polska's advisory. And in between, the CERT was already seeing what it describes without ornament: "In recent days we have been observing attacks against RouterOS devices accessible from the internet", with activity since at least 2 September. Which is to say: the attacks predate the patch.

There is one gesture from that 3 September we have not seen remarked on anywhere, and it says a fair amount about how urgent this felt on the inside. CERT Polska records it: "Along with this update, for the first time in history, MikroTik sent a push notification to the phones of users who had the MikroTik app installed". For the first time. A vendor that publishes dry release notes and lets you find out whenever you next look decided this time that people needed waking up on their phones.

There is a detail in the origin story that no longer surprises anyone and a year ago would have been the headline: the vulnerabilities "were discovered by Sławomir Rozbicki from the CERT Polska team using the GPT-5.5-cyber and GPT-5.6-sol models", in an automated laboratory environment. Six bugs in a heavily audited product, found by a team with models doing the sweeping. We already wrote about what that does to your timelines, and this is one more confirmation: the part that speeds up is the finding, not the fixing.

CISA's catalogue kept half the chain

We downloaded CISA's KEV catalogue file (version 2026.09.16, 1,713 entries) and went through it entry by entry. On 10 September two of these three went in: CVE-2026-86060 and CVE-2026-67277, both with a remediation due date of 13 September. Three days.

What is missing is CVE-2026-67276: the authentication bypass, the half that opens the chain. It changes nothing about what you have to do, because the package that fixes one fixes all three and the action is identical. What it does change is what the person ordering the patch queue off the catalogue sees: they will see the privilege escalation and the bandwidth-test memory leak, and they will not see the flaw that lets you in. We already argued, with the medium CVE that landed before the critical one, that the catalogue does not order your queue; that one was about a strange order, this one is about a missing piece. If your monthly report is generated by crossing inventory against KEV — and plenty of them are — this month's report does not mention the door.

In the same file there is a field almost nobody looks at, and here it separates the two entries: forensicTriage. For CVE-2026-86060 it reads Yes; for CVE-2026-67277, No. Meaning: for the one that grants privilege over SSH, CISA does not consider patching sufficient and additionally requires forensic triage under BOD 26-04. For the bandwidth-test one, it does not. If you need an argument to justify to management why you are spending a morning reading logs instead of twenty minutes upgrading, there it is, written by CISA in a JSON field.

122,500, and the vendor saying it ships closed

The figure that went around comes from Shadowserver, and it is worth quoting in full because the closing parenthesis is half the data: "At least 122,500 MikroTik devices with SSH accessible found per 24 hour scan window on 2026-09-05 (no vulnerability check)". One hundred and twenty-two thousand five hundred devices with the management service answering anyone who calls, counted in a single twenty-four hour window. Not 122,500 vulnerable devices: 122,500 that answer. The people doing the counting say so themselves.

And next to it, the other thing MikroTik said, with a revealing calm: "For regular home device users the issue does not pose an immediate risk, but we still suggest all users to upgrade". Translated: whoever bought the box and plugged it in as-is is reasonably safe. The risk lives where somebody made a decision.

It is worth not stretching that number further than it goes. We do not know how many of those 122,500 are business devices, how many are CPE managed by an operator over its own management network, how many are CHR instances at a cloud provider — which do not boot with a RouterBOARD's configuration — and how many are published deliberately and sensibly. Nobody publishes that breakdown. What the vendor has written down is that its factory configuration does not leave them that way, so for every one that is, somewhere along the line there is a hand.

And this needs qualifying before we go on, otherwise the whole article reads crooked. The six vulnerabilities are not all about the inbound port: according to CERT Polska they "affect the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface". The SSH client too. Which is why their second temporary measure is "Do not initiate TLS connections from an unpatched device or use the built-in SSH clients (/system ssh and /system ssh-exec)". Translated: a device with not one port open outward is not safe if it is the one doing the connecting. Everything that follows is about exposure, which is the part you decide; the upgrade has to happen either way.

Whoever opened that port was right that day

This is where it is tempting to slip into moralising, and it would be wrong. Management exceptions do not get opened out of sloppiness. They get opened because they are the right answer to a specific problem on a specific day: the site is ninety kilometres away, the primary line is down and you have to come in over the backup, the installer needs access on Saturday, the new monitoring has to reach the API, the carrier wants to see the device to diagnose it. The rule gets written, it works, the ticket closes, and everyone goes home having done their job properly.

What never happens is the other half. Nobody writes down when it stops being needed. Temporary exceptions are the only configuration change that is created with an expiry date in the head of the person making it and stored without one on the device. Which is why, three years later, the rule is still there and nobody left in the company can say why. And when a chain like MikroTrick turns up, what it finds is not this week's oversight: it finds a three-year-old decision nobody ever revisited.

There is one variant of that rule that deserves its own name because it is the most common: move the port. Shift SSH from 22 to 2222 and call it done. It removes background noise — the lazy mass sweeps stop calling — and that has real value in your logs. What it does not change is who can reach the service, which is the actual question. A targeted attack against a chain that grants full control of the device can afford to go looking for the port. This is our judgement, not a measurement: our impression is that the moved port has given a lot of people the feeling of having closed something that is still open.

If it was open, the patch does not close the matter

We have already argued here that upgrading is not cleaning, and we are not going to repeat the argument. What changes today is that here the patch does help you detect, and it is worth knowing exactly how far. A fixed RouterOS scans the configuration at boot, disables suspicious entries, logs warnings and marks the device as Flagged, a state you read with /system/device-mode/print. It is an excellent feature, and the sentence next to it in CERT Polska's advisory is the one to read twice: "the absence of the marker is not proof that the device is safe". The marker not showing up means nothing; it showing up means everything.

Which is why the two log lines CERT Polska publishes are worth more than the marker, and there are two of them, not one: login failure for user -2 from <ip> via ssh and, the one that actually proves something, user <name> added by ssh:-2@<ip>. The first says they tried. The second says they created an account. And in the configuration, a privileged user called ops that nobody created. What to review is listed in the advisory itself: users, scripts, scheduler tasks, proxy servers and tunnels. Scheduler tasks are the most forgotten and the best at surviving a reboot.

MikroTik finishes it off with a sentence that looks like boilerplate and is not, precisely because of its first half: "Even if your device is not in Flagged state, after upgrading your RouterOS, inspect your device configuration for any unknown scripts, users or other config you do not recognise". The vendor that has just handed you a detector is telling you, in the same line, not to rely on it alone.

The last two are the ones that would keep us awake about a border router, and not because they are sophisticated. A tunnel or a proxy on the device that separates your network from the internet survives you changing every password, shows up in no antivirus because there is no antivirus there, and is invisible from inside the LAN: to see it you have to look at the router's own configuration, which is precisely where nobody looks twice. Changing passwords gives a feeling of having acted that, in this scenario, corresponds to nothing.

What we would do this week

We run RouterOS ourselves too — we use it, CHR included — so this list is not advice for other people. It is ours.

• Upgrade, and know which version line each box is on before trying. The four fixed builds live on four different lines, three of them production ones: a real-world fleet has devices on 6.49, on 7.23 and on 7.24 at the same time, and jumping between lines is not the same work as moving within one. That list comes from the system, not the diagram; if it comes from the document you already know how it ends, because the spreadsheet lies.
• Save the log before touching anything, if the device was exposed. Here we depart from the order both sources recommend — they both say upgrade first and look afterwards — and we say so out loud so it can be argued with: a device with little log space that reboots can lose exactly the lines you are looking for. Copying the log off the box and noting down the user list takes a minute, and it decides whether this is an upgrade or an incident response, which are two different calendars and two different conversations with management. Then upgrade, without waiting.
• List the rules that publish management, and give them two things RouterOS already lets you write for free. In each rule's comment: who asked for it, and the date it dies. With that, a monthly review stops being an audit and becomes a list of names and expired dates. No new tool needed, just the writing. It is the cheapest thing on this list and the one that stops the next advisory, three years from now, finding the same rule. And no, RouterOS does not expire rules on its own: the date is enforced by a person reading a list.
• And then the path the vendor itself recommends, which is the one we follow. Their words: "use a strong VPN like WireGuard to access your router and do not open any management ports at all". The full sentence offers both options and ranks them: first "make sure only trusted IP can access it", and then that "or better yet". This is not our idea or a sales line: it is the vendor saying that filtering the port is fine and not having it is better. On when WireGuard and when IPsec, we already wrote an honest comparison, including the cases where the latter still wins.
• And bandwidth-test, the forgotten one. CERT Polska names it alongside SSH and WWW/WWW-SSL among the services to disable or restrict to trusted networks while you upgrade. It is a service somebody switches on one afternoon to measure a link and that stays on forever, exactly like the firewall rule. Same story, different line.

Closing management is not free either

It would be dishonest to end on "close everything" and leave it there. If you close management from the internet, you need another way in on the day the primary line is down — which is precisely the day you need to get in. That costs money: a 4G modem with its own tariff, a backup line, out-of-band access, or somebody with a key at a reasonable hour. Whoever opened that port three years ago very often opened it because that line item was not in the budget. Arguing about the port without arguing about the alternative route is asking someone to work with their hands tied.

And there is one case where this list cannot be applied: when the router is not yours. If your carrier manages it, you touch neither the version nor the rules. There the deliverable is not a rule, it is a written question — what version is running, when do you upgrade it, where is it administered from — and a date for the answer. The box belonging to somebody else does not move the outage to somebody else: the one left without service is still you.

Failure is inevitable; an outage is a design decision. In this case the design decision was not made by MikroTik on the day they published the CVE. It was made by somebody on your side, on an ordinary afternoon, solving something that needed solving. The blame is not theirs. The review is yours.

What we are not claiming

We are not saying RouterOS is less secure than others: we have no comparative figure putting any vendor above another, and we do not know how long MikroTik took between receiving the report and shipping the fix, because that date is not published. We do not know how many of the 122,500 devices Shadowserver counted are misconfigured; we know how many answer, which is not the same thing, and the count itself warns that it does not check whether they are vulnerable. We do not claim the chain has been used against any specific company, nor do we know of named victims. We are not an interested party either: we do not resell MikroTik or any other networking vendor. And we are not reproducing the two IP addresses CERT Polska cites: an indicator of that kind ages in days, and publishing it as a blocklist does more harm than good.

Note on sources

All consulted on 18 September 2026. One: the CERT Polska advisory "Critical vulnerabilities in MikroTik RouterOS are being actively exploited" (5 September 2026), source of the six coordinated vulnerabilities and the components they affect ("the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface"), the three detailed CVEs with their CVSS scores and literal descriptions, the MikroTrick name, the sentence about full control without authentication, the observation of attacks since at least 2 September, MikroTik's push notification for the first time in its history, the Flagged mechanism with /system/device-mode/print and its warning that "the absence of the marker is not proof that the device is safe", the two log lines and the ops user, the list of what to review (users, scripts, scheduler tasks, proxies and tunnels), the temporary measures — disable or restrict SSH, WWW/WWW-SSL and bandwidth-test, and do not initiate TLS connections or use the built-in SSH clients from an unpatched device — and the attribution of the finding to Sławomir Rozbicki using the GPT-5.5-cyber and GPT-5.6-sol models. Two: MikroTik's security page on the September 2026 vulnerability, source of the four fixed builds dated 3 September and the quoted sentences: the "important security update" one, the one about not publishing detail yet, the one about the port being blocked by default, the WireGuard one, the home-user one, and the one about inspecting the configuration even if the device is not in Flagged state. Three: the CISA KEV catalogue JSON file, version 2026.09.16 with 1,713 entries, downloaded and filtered by us: that is where the addition date (10 September) and remediation deadline (13 September) for CVE-2026-86060 and CVE-2026-67277 come from, along with the absence of CVE-2026-67276 and each entry's forensicTriage field. Four: the Shadowserver figure of 5 September 2026, quoted verbatim — parenthesis included — in the coverage of the case; we were unable to check it on the original dashboard. What is our opinion, flagged as such in the body: that a moved port gives a feeling of closure without being one, that temporary exceptions are created with an expiry date and stored without one, the list of what we would do this week, and the decision to save the log before upgrading, which departs from the order the sources recommend.