Your MikroTik Router Is Patched. Is There Still a User Called ops on It?

The first confirmed takeovers happened on September 2. MikroTik published fixed RouterOS builds on September 3 and described them only as "an important security update." CERT Polska explained what that update actually closed on September 5. CISA added two of the CVEs to the Known Exploited Vulnerabilities catalog on September 10 with a remediation date of September 13. If you run a MikroTik router that answers SSH from the internet, that eight-day gap is the thing you have to account for.

The exploit chain is called MikroTrick. CERT Polska found six vulnerabilities in RouterOS through internal research by Sławomir Rozbicki, and two of them combine into an unauthenticated path to full administrative control over SSH. No password, no stolen key, no user interaction.

This one is yours if you run RouterOS below 6.49.21, 7.23.4 or 7.24.2 and the SSH service answers anything you do not control. MikroTik's stock firewall blocks SSH from the WAN, so the exposed population is the devices where somebody opened the port on purpose: the branch router an MSP reaches over the internet, the customer premises equipment a small ISP manages in bulk, the lab box that got a public address in 2021 and never lost it. The Shadowserver Foundation counted more than 122,500 MikroTik devices with SSH reachable from the internet in a single 24-hour scan window on September 5. If every MikroTik you own binds its management services to an internal VLAN and you can prove port 22 has never answered from the WAN, upgrade on your normal change schedule and go spend the afternoon on the September Patch Tuesday queue instead.

Here is the part that changes the response plan for everyone else. An attacker who used this before you upgraded created a real user account on a real router. That account is a legitimate configuration object. The upgrade does not remove it, the reboot does not remove it, and nothing in the release notes tells you to go look.

What MikroTrick chains together

The front half is CVE-2026-67276, rated 9.2 and classified as CWE-347, improper verification of a cryptographic signature. RouterOS compared only the public modulus of a user's RSA key against the authorized key rather than the whole key. An attacker who knows an authorized modulus can present a key that carries the same modulus with a public exponent of one, and forge a signature without ever holding the private key. That yields a session.

The back half is CVE-2026-86060, also rated 9.2, classified as CWE-88, improper neutralization of argument delimiters. A username that begins with a prohibited character changes the trusted policy mask RouterOS applies during login. The session that comes back holds full administrative policy. CISA's catalog entry describes the same behaviour in one line: an attacker can change the trusted RouterOS policy mask, leading to privilege escalation.

Read the affected ranges rather than the headline, because they differ. The signature bug reaches 7.9 up to 7.23.4 and 7.24 up to 7.24.2. The policy-mask bug reaches all the way back to 6.0.0. A device on the v6 long-term branch is outside the front half of the chain and still inside the half that hands out administrative policy, which means "we are on 6.x, that story is about 7.x" is wrong in the direction that costs you.

The third CVE that CISA listed, CVE-2026-67277 at 8.8, is a separate surface. The bandwidth-test service lets an unauthenticated client reach a state reserved for logged-in clients and start an IPv4 UDP test. Uninitialized packet-buffer contents and an integer underflow in size validation then expose kernel memory or restart the device. It does not participate in the takeover, and it is running on a lot of routers whose owners have never used btest for anything.

The remaining three from the same research sit in the same fixed builds: an X.509 validation weakness that accepts malformed PKCS#1 signatures against public root certificates when the exponent is three, a rekey path that performs file operations without completing authentication, and a stale uninitialized pointer in the WebFig /jsproxy session handler that permits directory traversal into configuration files.

Notice which two CISA actually catalogued: CVE-2026-67277 and CVE-2026-86060. The signature bypass that opens the door is not on the KEV list. Anyone patching by KEV entry rather than by fixed build would close the escalation and leave the front door standing. The unit of work here is the version number, not the CVE list.

Eight days of "important security update"

Reconstruct the timeline, because the lesson lives in the order of events.

CERT Polska reported observing attacks against internet-reachable RouterOS devices from at least September 2. MikroTik shipped 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21 on September 3. Its advisory said the update was important, that most configurations were not at risk, and that "to give time to update your systems, we are not currently publishing detailed information." No CVE numbers, no CVSS, no mechanism. CERT Polska published the six CVEs on September 5. CISA added two of them to KEV on September 10 under BOD 26-04, due September 13.

Withholding detail to buy customers patching time is a defensible choice, and MikroTik made it while the bugs were already being exploited. The consequence for you is operational. For two days the only signal available was a changelog line with no severity attached to it, and the population of devices that got upgraded in those two days is the population whose owners treat an unexplained RouterOS security release as a maximum rather than a minimum. Everyone who waited for a CVE number to justify the change window gave the attackers three days.

That is a policy decision you can make once, in advance, and it costs nothing: MikroTik security releases get the same treatment as an emergency Fortinet or Citrix advisory, regardless of how the release note is worded.

Find out whether somebody already visited

CERT Polska published usable indicators. The exploitation attempt leaves failed SSH logins for a username of -2, which is not a valid account and has no business in any log. A successful run shows configuration actions attributed to the bypassed session, in the form user <name> added by ssh:-2@<ip>. Across the observed attacks the account created was named ops. Two source addresses are associated with the activity: 82.192.72[.]4, the origin of the successful compromises, and 103.102.31[.]18. RouterOS also runs its own compromise check on upgrade and writes a critical log entry marking the device as Flagged.

Run these on each device. Ten minutes per router, and they answer the question the upgrade cannot.

# 1. Which build is this, and is it one of the fixed ones?
/system resource print
/system package update check-for-updates

# 2. The exploitation artifact: SSH activity for the user "-2"
/log print where message~"-2"
/log print where message~"critical"

# 3. Configuration changes attributed to a bypassed session
/system history print

# 4. Accounts, keys and policy you did not create
/user print detail
/user ssh-keys print
/user group print detail

# 5. Persistence: scripts, schedulers, proxies, tunnels, sniffers
/system script print detail
/system scheduler print detail
/ip socks print
/ip proxy print
/tool sniffer print
/interface print where type~"(eoip|gre|vxlan|l2tp|pptp|wireguard)"

# 6. What is listening, and to whom
/ip service print
/tool bandwidth-server print
/ip firewall filter print where chain=input

How to read the output

• Any user other than the ones your team created, and specifically anything called ops, is a compromise until proven otherwise.
• An SSH public key in /user ssh-keys print that nobody can match to a current engineer is the same finding.
• A scheduler entry or script you did not write is how the access survives your upgrade.
• A SOCKS proxy or a tunnel interface on a router that has never needed one means the device was somebody's route into the rest of the network, not the target.
• An empty /log is not a clean result. RouterOS log buffers are small, they roll, and an attacker with administrative policy can clear them. Absence of the -2 artifact proves nothing on a device that was exposed.

Close the services that carried it

Upgrading fixes the bugs. Reducing the surface is what keeps the next RouterOS advisory from being an emergency. MikroTik's own guidance is to keep management off the internet entirely and reach the router over a VPN, which is the correct answer and the one most exposed devices are not configured for.

# Bind management services to the trusted network, drop the rest
/ip service set ssh address=10.10.0.0/24 port=22
/ip service set winbox address=10.10.0.0/24
/ip service disable telnet,ftp,www,api,api-ssl

# The CVE-2026-67277 surface. Turn it off unless you run bandwidth tests.
/tool bandwidth-server set enabled=no

# Backstop the service ACLs with a filter rule at the top of the input chain
/ip firewall filter add chain=input in-interface-list=WAN protocol=tcp \
    dst-port=22,23,80,443,8291,8728,8729 action=drop \
    comment="drop mgmt from WAN"
/ip firewall filter move [find comment="drop mgmt from WAN"] destination=0

Set address= on the service rather than relying only on the firewall. Service ACLs and filter rules fail in different ways, and a RouterOS upgrade that resets an interface list should not silently reopen port 22.

What to do with a Flagged device

If RouterOS marked the device Flagged, or you found an account you cannot explain, the upgrade is step one of five and deleting the extra user is not step two.

Isolate the device first, then export the running configuration and the logs before you change anything, because that export is the only evidence you will get. Rotate every credential the router held, not only the admin password: PPPoE and RADIUS secrets, IPsec pre-shared keys, WireGuard and OpenVPN material, SNMP communities, and any SSH key with a copy on the box. Assume anything that transited the device while it was under someone else's administrative control is known to them.

Then rebuild rather than clean. On a device where an attacker held full policy, the honest position is that you cannot enumerate everything they touched, and RouterOS gives an administrator enough surface - scripts, schedulers, NAT rules, certificates, a packet sniffer streaming to a remote collector - that a line-by-line review of an exported config is a worse use of an afternoon than a Netinstall and a known-good configuration reapplied from your own repository. If you do not have that known-good configuration in version control, building one is the actual finding from this incident.

Last, look upstream and downstream. A compromised edge router is a position, and the useful question is what it had reach into. Check what the device could talk to on the inside, and pull authentication logs for the internal systems that trusted traffic arriving through it.

Read the user list on every RouterOS device tonight

The upgrade takes twenty minutes and a reboot window. Reading /user print detail and /system history print on every MikroTik in the fleet takes longer, and it is the step that separates a patched router from a clean one. Do the version check across the fleet first, then the user audit, and put the results somewhere durable so the next person can tell which devices were actually reviewed.

If you found an account you cannot account for and you do not have a written sequence for what happens next, that gap is worth more attention than the CVE. We build and test incident response playbooks with teams who have to do this work themselves, on the equipment they actually run.