CISA listed two exploited MikroTik flaws on September 10. Neither of them is the authentication bypass attackers are actually using.

Most small businesses can name their laptops, their phones and their cloud accounts. Almost nobody can name the router.

It is a small box in a closet, on a shelf above the ceiling tiles, or in the corner of the server rack, and it was installed by an internet provider or a contractor on a day that everyone has forgotten. It has never been updated because there was never a reason to update it. Nothing on it has ever broken.

That box runs software, the software has a version number, and for the past two weeks one particular brand of it has been getting taken over by people who scan the entire internet looking for it.

Everything below was checked against primary sources on September 15, 2026: CERT Polska’s advisory and its exploitation warning, MikroTik’s own security bulletin, the RouterOS changelog files served from MikroTik’s upgrade servers, MikroTik’s product documentation, CISA’s Known Exploited Vulnerabilities feed, NVD, and the Canadian Centre for Cyber Security’s advisory.

What happened

On September 5, 2026, CERT Polska, Poland’s national computer emergency response team, published six vulnerabilities it found in MikroTik RouterOS, the operating system that runs on MikroTik routers and on the Cloud Hosted Router virtual appliance. All six were found by Sławomir Rozbicki of CERT Polska through the team’s own research and disclosed to MikroTik under coordinated disclosure.

Two of the six chain together. CERT Polska gave the chain a name so people could talk about it, MikroTrick, and described the result in one sentence:

Combining two of them allows an attacker to take full control of the device without authentication if the device supports remote access using the SSH protocol.

The same post carries the part that turns this from a maintenance item into tonight’s work:

In recent days we have been observing attacks against RouterOS devices accessible from the internet. We have obtained confirmation that the attackers are exploiting this combination of vulnerabilities to take full control of devices whose SSH service is accessible from public networks.

MikroTik shipped fixes two days before that, on September 3, 2026, in 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21. CERT Polska’s analysis puts the successful attacks it observed, including the creation of an unauthorized account, as “occurring since at least 2 September,” from the IP address 82.192.72.4, with a second address, 103.102.31.18, used in further attempts. September 2 is the day before the patch existed. This was a zero-day before it was a patch note.

The six vulnerabilities, and which ones matter

All six are fixed by the same upgrade, so for anyone who simply updates, the distinctions below do not change what you do. They matter enormously if you are deciding whether to update at all, or triaging with a scanner, or applying a mitigation instead of a patch.

CVE	What it is	CVSS 4.0 (CERT PL)	Needs authentication?
CVE-2026-67276	SSH authentication bypass: incomplete RSA public key comparison	9.2	No
CVE-2026-86060	Privilege escalation via a crafted SSH username	9.2	No
CVE-2026-67281	WebFig unauthenticated file read of root-owned files, including credential stores	8.7	No
CVE-2026-67277	Bandwidth-test service: kernel memory disclosure and remote restart	8.8	No
CVE-2026-67279	SSH: unauthenticated file creation and overwrite after a client-requested rekey	6.9	No
CVE-2026-67278	Malformed RSA signatures accepted during X.509 validation, enabling TLS impersonation	6.3	No

Every one of them is reachable without logging in. NVD has finished its own analysis on two so far and scored them higher than CERT Polska did on the older CVSS 3.1 scale: CVE-2026-86060 at 9.8 and CVE-2026-67277 at 8.2.

How MikroTrick works

CVE-2026-67276 is the interesting one, and the mechanism is worth understanding because it explains who is exposed.

When you log into a router with an SSH key, the server has to answer one question: does the key this client is presenting match the key on file for this user? RouterOS answered it by comparing the key type and the RSA modulus, the large number at the heart of an RSA public key. It did not compare the exponent, the second half of the key. In CERT Polska’s words:

RouterOS does not compare the complete RSA public key when matching an SSH authentication request to an authorized user key, checking the key type and modulus but omitting the exponent. Because signature verification uses the client-supplied key, an attacker knowing an authorized RSA modulus can supply a key with exponent one, forge a valid signature, and open an SSH command channel as the target user without the private key.

Exponent one is the punchline. Verifying an RSA signature means raising the signature to the power of the exponent and checking the result against the hash of what was signed. Raise anything to the power of one and you get the thing itself, so an attacker who is allowed to choose the exponent can simply hand over the expected value as the “signature” and it verifies. The private key never enters into it.

The precondition is that the attacker knows a username on the device and the modulus of a public key assigned to it. Public keys are not secrets by design, which is the whole point of them. Anybody who has ever been sent one has the modulus: a former contractor, a hosting provider, a colleague, an old ticket in a helpdesk system. GitHub, to take one ordinary example, serves every user’s public SSH keys through a documented, unauthenticated REST endpoint, because that is what a public key is for. If the person who set up your router uses the same key everywhere, the first half of MikroTrick costs an attacker nothing.

CVE-2026-86060 is the second half. RouterOS mishandles usernames beginning with a disallowed character in the SSH login path, and a crafted username lets an attacker change the policy mask attached to the session. CERT Polska: “The resulting session had full administrative privileges in the RouterOS system.”

Put them together and you get an unauthenticated stranger with a full administrative console on the device that every packet in your office passes through.

The finding: the exploited bug is not on CISA’s list

Here is the part we have not seen said anywhere, and it is checkable in about a minute.

On September 10, 2026, CISA added two MikroTik RouterOS vulnerabilities to the Known Exploited Vulnerabilities catalog. We downloaded the feed this morning at catalog version 2026.09.14, which holds 1,710 entries, 226 of them added during 2026. The two MikroTik entries added on September 10 are:

• CVE-2026-86060, “Improper Neutralization of Argument Delimiters in a Command Vulnerability”
• CVE-2026-67277, “Missing Authentication for Critical Function Vulnerability”

CVE-2026-67276, the SSH authentication bypass, the half of MikroTrick that gets an attacker onto the device in the first place, is not in the catalog. Not on September 10, and not at catalog version 2026.09.14 five days later. CISA’s own alert page for that day names the same two CVEs. Several outlets have written that CISA added the auth bypass. It did not.

We are not saying CISA got it wrong. KEV records vulnerabilities with evidence of exploitation attached to that specific CVE, and CISA presumably has evidence for the two it listed. The problem is downstream, in what people do with the list.

A large number of small businesses, and a larger number of the IT shops that serve them, now run a workflow that amounts to: if it is on KEV, it is urgent; if it is not, it goes in the queue. We have recommended a version of that ourselves, because KEV is the best free triage feed in existence. This is the case that shows its edge. Read the two MikroTik entries on their own and you get a fair but incomplete picture: a privilege escalation, and a bandwidth-test flaw whose description ends in “kernel memory disclosure and denial of service.” Neither entry tells you that an unauthenticated attacker can arrive as an existing user.

The practical failure modes are specific:

• Anyone who reads the btest entry and responds by disabling the bandwidth-test server as a mitigation, rather than upgrading, has addressed the least dangerous of the six and left the chain that is actually being used intact.
• Anyone whose vulnerability scanner reports KEV-listed CVEs only sees a high and a critical, not the 9.2 auth bypass.
• Anyone who reports upward on “exploited vulnerabilities addressed” closes this out looking complete.

The fix for all of it is the same: on this product, this month, patch the version, not the CVE list. There are six flaws, they are all pre-authentication, and one upgrade closes all six.

The second finding: install 7.23.5, not 7.23.4

MikroTik’s advisory tells you the fix is in 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21. CERT Polska repeats the same four versions. Both were correct when written, and one of them is now the wrong thing to install.

We pulled MikroTik’s own release pointers from its upgrade servers this morning. The long-term channel does not point at 7.23.4 any more:

Channel	Current version	Released (UTC)
Stable (v7)	7.24.2	2026-09-03 09:57
Long-term (v7)	7.23.5	2026-09-04 05:32
Long-term (v6)	6.49.21	2026-09-03 11:45

Then we read the changelog files MikroTik serves for each release. The one for 7.23.5, in full:

The 7.23.4 release was an important security update. Most configurations are not at risk, but upgrading is highly recommended. To give you time to update your systems, we are not publishing detailed information yet. This release, 7.23.5, additionally addresses an urgent issue introduced in 7.23.4.

*) dhcp - fixed IPv6 DHCP functionality (introduced in v7.23.4);

So the long-term security release broke IPv6 address assignment, and the fix went out the following morning. If you are on the long-term branch and you follow the advisory literally, you install a version with a known IPv6 DHCP regression, and on a network where clients get their addresses over IPv6 you find out about it immediately, in the way that makes people roll back security patches. Go to 7.23.5.

The third finding: the changelogs say “improve stability”

There is a reason a competent administrator could have read MikroTik’s release notes on September 3 and decided this one could wait.

Here is what the 7.24.2 changelog actually says about six unauthenticated vulnerabilities, verbatim from the file MikroTik serves:

*) btest - improve stability;
*) certificate - fix changing the built-in trust store setting (introduced in 7.22.2);
*) ssh - refactor SSH internal processes and improved system stability;
*) webfig - improve stability;
*) www - improve stability;

Those five lines are, as far as we can map them, the SSH authentication bypass, the SSH privilege escalation, the SSH rekey flaw, the bandwidth-test memory disclosure, the X.509 signature flaw and the WebFig unauthenticated file read. There is not a CVE number anywhere in the file. The header does say “This is an important security update,” and MikroTik’s advisory explains why the detail is missing: “To give time to update your systems, we are not currently publishing detailed information.”

That is a defensible embargo strategy and it has a cost. Every patching process that works by reading release notes and judging urgency was handed the word “stability” six times. The version-level signal, “important security update,” was there and it was the only signal there. If your update policy has a rule that says security releases go in immediately and feature releases wait for a window, this is the month that rule earned its keep.

Worth noting on the other side: CERT Polska says that 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.” The vendor did try to reach people. It reached the ones with the app.

Are you even affected?

Three questions, in order.

1. Do you have a MikroTik? You may not know. MikroTik is a Latvian manufacturer whose hardware is cheap, extremely capable and very widely used by internet providers, wireless ISPs, hotels, cafés with guest wifi, and the independent IT contractors who wire small offices. It is not a consumer brand, so it tends to arrive through somebody else. Tells: a device with a metal or white plastic case labelled hEX, hAP, RB, CCR or CRS; a router administration page at 192.168.88.1, the RouterOS default; a management tool called WinBox, which talks on port 8291.

The Cloud Hosted Router version is worth naming separately, because it does not look like a box at all. It is RouterOS running as a virtual machine, on a cloud provider or a hypervisor, and per MikroTik’s documentation its default user is “admin, without a password.”

2. Is SSH reachable from outside? MikroTik’s advisory says, correctly, that “MikroTik default configuration blocks this port from the internet by default, but if you have manually opened this port, make sure only trusted IP can access it.” That default firewall is the single reason this is not a catastrophe for every MikroTik on earth. It is also the thing most likely to have been changed, by whoever needed remote access at 9pm on a Sunday two years ago and never took the rule out.

Note what the default is not. In RouterOS the ssh service itself is enabled by default on port 22, alongside ftp, telnet, www, winbox, api and api-ssl, per MikroTik’s own services documentation. The firewall is what keeps the internet away from it, not the service configuration. Anything running RouterOS without that default firewall in front, which includes Cloud Hosted Router instances built from scratch and plenty of devices configured by hand, is exposed by nothing more than a missing rule.

3. What version is on it? If it is below 7.23.5, 7.24.2 or 6.49.21, it is vulnerable to all six.

The bandwidth-test detail that matters

One thing worth spelling out, because it is the kind of assumption that survives a patch cycle.

RouterOS ships with the bandwidth-test server enabled by default, and with authenticate: yes, per MikroTik’s documentation. Reading that, a reasonable administrator concludes the service is safe because it demands credentials.

CVE-2026-67277 is precisely the failure of that assumption. In CERT Polska’s description, “the bandwidth-test service allowed an unauthenticated connection to enter a state that should only be reachable after logging in.” The authentication setting was on. The code path that mattered ran before it. This is the general shape of most pre-authentication bugs and it is why “we require a password” is never, by itself, an answer to a question about exposure.

What to do today

1. Upgrade. Long-term branch: 7.23.5. Stable branch: 7.24.2. RouterOS 6: 6.49.21. The advisory also lists 7.25 beta 3, which is a beta; unless you are already on the testing channel, take one of the other three. MikroTik notes that the device will offer the upgrade in its “Check for updates” menu.

2. Then check whether somebody got there first. The attacks CERT Polska observed left specific marks. In the RouterOS log:

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

The literal string -2 where a username belongs is the artifact of the crafted-username flaw, and it is the thing to search for. CERT Polska also reports “the presence of a highly privileged user named ops” as an indicator of compromise. Check your user list against people who actually exist.

3. Check the Flagged marker. The patched releases include a mechanism that scans the configuration at startup for known signs of unauthorized changes, disables what it recognises, writes a critical log entry and sets a “Flagged” status. Read it with:

/system/device-mode/print

Two cautions, both from the sources rather than from us. CERT Polska: “This mechanism detects only selected traces left after a compromise, the absence of the marker is not proof that the device is safe.” And MikroTik’s own documentation: “If your system has been flagged, you should assume that your system has been compromised and do a full audit of all settings before re-enabling the system for use.”

Plan for what flagged state means operationally, because it bites. While a device is flagged, RouterOS blocks bandwidth-test, traffic-generator and the sniffer, and blocks enabling or creating new entries for the scheduler, SOCKS proxy, PPTP, L2TP, IPsec, proxy and SMB. Clearing it is not a remote operation: the documented procedure is /system/device-mode/update flagged=no, after which “the system will ask to either press a button, or issue a hard reboot (cut power physically or do a hard reboot of the virtual machine).” If the router is at a site an hour away, that is a drive. If it is a Cloud Hosted Router, it is a hard power cycle of the instance.

4. If it was reachable and it is not patched, treat it as compromised. CERT Polska’s guidance, and ours: isolate the device, secure the logs and configuration before you reset anything, restore to factory settings, reconfigure from a configuration you trust rather than from a backup taken off the suspect device, and change every password, key and secret the device held. Do not clear the Flagged marker before the evidence is preserved.

That last part is the expensive part, and it is the part people skip. A router holds VPN pre-shared keys, PPPoE credentials, wireless passphrases, SNMP community strings and often a saved backup of itself. An attacker with an admin console had all of them.

5. If you cannot patch tonight, reduce the surface. CERT Polska’s temporary measures, which explicitly do not replace the update: block or disable exposed services, particularly SSH, WWW, WWW-SSL and the bandwidth-test server, from everything outside a trusted management network; and do not initiate TLS connections or use the built-in SSH client (/system ssh) from an unpatched device, because two of the six flaws are in RouterOS as a client rather than as a server.

If somebody else runs your network

Most of the businesses we work with in Toronto did not configure their own router and could not log into it if they wanted to. That is a perfectly reasonable way to live. It means this week’s work is one email rather than one console session.

Three questions, and a reasonable provider will have the answers ready:

1. Do we have any MikroTik devices, and what RouterOS version are they on? The version number is the whole answer. “We are on 7.24.2” ends the conversation.
2. Was SSH, WebFig or WinBox reachable from the public internet on any of them at any point since September 2? If yes, the second question is what they found in the logs.
3. If a device is flagged or suspect, who is driving to the site, and when? This is the question that surfaces whether anybody has actually looked.

This is the same conversation we recommended when the remote-management tool your IT provider uses got broken into, and the same one after an unauthenticated flaw in Cisco’s firewalls that had no workaround. The pattern is consistent enough to be a planning assumption now: the devices at the edge of small networks are maintained by somebody two steps removed from the business that carries the loss, and they are the most attacked class of equipment on the internet. Cisco alone has sixteen entries on CISA’s exploited list this year, the newest added yesterday: an unauthenticated SQL injection in Secure Email Gateway that CISA describes as allowing an attacker “to execute arbitrary commands with root privileges on the underlying operating system,” with a remediation deadline of September 17 and the forensic triage flag set.

In Canada, the Canadian Centre for Cyber Security published its MikroTik advisory on September 8 and updated it on September 10, noting that “open-source reporting indicates that CVE-2026-67276, CVE-2026-67277 and CVE-2026-86060 related to MikroTik are being exploited in the wild,” and issued a separate alert for IT professionals on September 10. If you need something official to forward to a provider or an insurer, that is the Canadian document to send.

The part that is about AI, and is not hype

One detail in CERT Polska’s write-up deserves attention from anyone tracking what AI is doing to security, in either direction.

The six vulnerabilities were found “using the GPT-5.5-cyber and GPT-5.6-sol models as part of the team’s access to the OpenAI Government and Trust Agency Collaboration (GTAC) program,” inside an agent-driven research lab with real RouterOS machines. CERT Polska is careful about what that did and did not mean:

This was not, however, the result of a single instruction (prompt). Every hypothesis required confirmation on a real RouterOS system, negative control tests, repetition on a machine in a clean state, and an impact assessment by the researchers.

They also name the technique that worked, which is more useful than the headline: “Modelling protocols as state machines and checking what happens when a stage is skipped, repeated, or executed in the wrong order proved particularly effective.” Look at the list of six. A btest session that reaches a post-login state before login. An SSH connection that enters the connection protocol after a rekey with no authentication attempted. That is the same bug, found twice, by a method aimed directly at it.

We have argued before that AI-discovered vulnerabilities are not yet what breaks small businesses, and the data still says that. This is the strongest counter-example so far, with one important wrinkle: the exploitation started on September 2, three days before CERT Polska published and one day before the patch. Whoever was attacking these routers was not reading the AI-assisted research. They found their own way in, or bought it. The AI pipeline produced the fix, not the attack.

What we could not verify

• The exposure count. The number in wide circulation is roughly 122,500 MikroTik devices with SSH reachable from the internet, attributed to the Shadowserver Foundation on September 5, with broader RouterOS exposure quoted above 400,000. We could not pull either figure from a Shadowserver source directly, so we are not presenting it as ours. Treat it as reported, not confirmed.
• Whether CVE-2026-67277 is being exploited separately. CISA listed it, which under its own criteria means it has evidence. CERT Polska’s exploitation reporting describes the MikroTrick chain, which does not include it. Both statements can be true and we cannot reconcile them from public sources.
• The mapping from changelog lines to CVEs. MikroTik published no CVE-to-changelog mapping, so the alignment above between the “improve stability” entries and the six flaws is our reading based on the affected components CERT Polska names. The direction is not in doubt; the line-by-line assignment is inference.
• How many RouterOS installs use SSH public key authentication at all. The auth bypass needs a username and an authorized key modulus. Installs with no SSH keys configured are not exploitable by that half of the chain. Nobody publishes that population, and it changes nothing about the other five flaws.
• Whether a public exploit exists. CERT Polska explicitly withheld exploit code and said it published early because “comparative analysis has allowed the community to reconstruct some of the fixed bugs” from the patched packages. We found references to proof-of-concept work in secondary coverage that we could not open and confirm. Assume reconstruction is done.

The short version

If you have a MikroTik router, update it tonight: 7.23.5 on the long-term branch, 7.24.2 on stable, 6.49.21 on RouterOS 6. If SSH or WebFig was reachable from the internet at any point since September 2, search the logs for user -2 and for an account called ops, run /system/device-mode/print, and treat a Flagged device as compromised rather than as cleaned.

If you do not know whether you have a MikroTik, that is the actual finding, and one email to whoever installed your network answers it.

And if you triage security work off CISA’s exploited list, keep doing it, with one adjustment: the list names the CVEs with evidence attached, not the chain. On this one, the entry that would have told you to hurry is the one that is not there.

If you want a second pair of eyes on any of this, get in touch. We are in Toronto, this is the kind of thing we look at for clients, and the conversation is shorter before the incident than after.

Sources

• Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended, CERT Polska, September 5, 2026, for the MikroTrick name, the quoted description of the chain and of active exploitation, the CVSS 9.2, 9.2 and 8.8 figures, the indicators of compromise including the -2 log strings and the ops account, the attacking IP addresses 82.192.72.4 and 103.102.31.18 and the “since at least 2 September” timing, the Flagged mechanism description and caveat, the temporary mitigations, the push notification detail, the LLM-assisted research description and quotes, and the reason for publishing early
• Vulnerabilities in Mikrotik RouterOS software, CERT Polska, September 5, 2026, for all six CVE records, their CWE classifications, the per-CVE technical descriptions quoted above, the affected version ranges and the fixed versions
• MikroTik September 2026 vulnerability, MikroTik, September 3, 2026, for the quoted advisory text, the four fixed versions, the “Check for updates” instruction, the statement that the default configuration blocks SSH from the internet, and the Flagged follow-up instructions
• RouterOS changelog files retrieved from https://upgrade.mikrotik.com/routeros/<version>/CHANGELOG for 7.24.2, 7.23.4, 7.23.5 and 6.49.21 on September 15, 2026, for the quoted release text including the 7.23.5 IPv6 DHCP regression note and the “improve stability” entries, and the channel pointer files NEWESTa7.stable, NEWESTa7.long-term and NEWESTa6.long-term for the current versions and their release timestamps. The mapping of changelog lines to CVEs is our own analysis.
• Known Exploited Vulnerabilities Catalog JSON feed, CISA, downloaded September 15, 2026 at catalog version 2026.09.14, for the 1,710 total entries, the 226 added during 2026, the full text of the CVE-2026-67277 and CVE-2026-86060 entries including the September 13 remediation deadline and the forensic triage flags, the absence of any CVE-2026-67276 entry, the sixteen Cisco entries added in 2026, and the September 14 Cisco Secure Email Gateway entry and its quoted description. The counts are our own analysis of that file.
• CISA Adds Two Known Exploited Vulnerabilities to Catalog, CISA, September 10, 2026, for the two CVE IDs added that day and the note that while BOD 26-04 applies only to federal agencies, CISA encourages all organizations to prioritize KEV remediation
• NVD records for CVE-2026-67276, CVE-2026-67277, CVE-2026-67278, CVE-2026-67279, CVE-2026-67281 and CVE-2026-86060, queried through the NVD API on September 15, 2026, for publication dates, analysis status, the CERT Polska CVSS 4.0 vectors and the NVD CVSS 3.1 scores of 9.8 and 8.2
• Mikrotik security advisory (AV26-887) Update 1, Canadian Centre for Cyber Security, issued September 8, 2026 and updated September 10, 2026, for the quoted statement on in-the-wild exploitation and the affected versions
• Services, Bandwidth Test, Device-mode, First Time Configuration and Cloud Hosted Router, CHR, MikroTik documentation, for the default services table and enabled ssh service, the bandwidth-test server defaults of enabled: yes and authenticate: yes, the flagged-state restrictions and the quoted clearing procedure, the 192.168.88.1 default address, and the CHR default user with no password
• Users keys, GitHub REST API, for the GET /users/{username}/keys endpoint that returns a user’s verified public SSH keys and is, in GitHub’s wording, “accessible by anyone.” Used only as an ordinary illustration that public keys are published on purpose, not as a claim about any specific person’s router.
• Hackers exploit new MikroTik RouterOS flaws to hijack routers, BleepingComputer, September 7, 2026, for the reported Shadowserver figure of 122,500 devices with SSH exposed as of September 5, which we could not confirm at source