2026-09-06

MikroTik under fire: six RouterOS flaws attackers are already chaining together

Security

If your network has even one MikroTik router with SSH or WebFig exposed to the internet, this is worth reading to the end. CERT Polska has published a breakdown of six RouterOS vulnerabilities, some of which can be chained into an attack path researchers are calling MikroTrick. Worse, this isn’t a theoretical scenario. CERT Polska confirmed real exploitation attempts against internet-facing devices.

What was actually found

The CERT Polska analysis covers six bugs: CVE-2026-67276, CVE-2026-67277, CVE-2026-67278, CVE-2026-67279, CVE-2026-67281, and CVE-2026-86060. They sit in different parts of the system: SSH, WebFig, the bandwidth-test service, and X.509 certificate verification. So there’s no single root cause here. Some allow authentication bypass, some break access control after login, others lead to memory disclosure or a plain device crash.

Two of the SSH bugs got the most attention from CERT, because together they give an attacker more than either one on its own.

How someone can impersonate an administrator (CVE-2026-67276)

An RSA public key is, in short, a pair of numbers: the modulus n and the public exponent e. Changing either one should produce a different key. That’s how a correct implementation is supposed to behave.

RouterOS didn’t enforce that. When comparing the key a client presented over SSH against the key assigned to an account, the system checked the modulus n but didn’t properly validate the exponent e. The result: two different keys sharing the same modulus could be treated as the same user key. CERT demonstrated this by crafting a key with e = 1, a parameter that strips the entire RSA operation of any security value.

It gets worse. The signature check that followed also relied on parameters supplied by the client. Anyone who knew a user’s public key could craft their own key and signature, and RouterOS would simply accept them. This isn’t a break of RSA itself, and no private key is recovered. It’s a logic flaw that fails to treat a public key as one indivisible cryptographic value. The practical outcome is real: impersonating a user configured to log in with an RSA key.

When authentication stops mattering (CVE-2026-86060)

The second piece of the puzzle concerns what happens right after, granting session permissions. RouterOS decides what a given SSH session is allowed to do, administer the device, read configuration only, or something else, based on an internal permission mask.

CERT found that a specially crafted username can be misinterpreted while that context is being built. This is a textbook argument injection issue (CWE-88). It isn’t about executing a system command. It’s about a crafted value altering the parameters that control session security policy. In practice, a session ends up with more access than it should have. CERT confirmed this can be used to obtain a full set of RouterOS privileges.

The difference between these two flaws matters. The first answers the question of whether someone is who they claim to be. The second answers a different question: what permissions the session they already created will get. Combined, they let an attacker walk through both security checks at once, which is exactly what CERT named MikroTrick. A mismatched key gets you past authentication, and a manipulated permission mask hands you full administrative access on the other side.

Four more bugs, four different mechanisms

The remaining flaws work independently of the SSH pair, though a couple still touch that same protocol.

CVE-2026-67279 sits in the SSH state machine itself. SSH has a defined order: transport setup, key exchange, user authentication, and only then channels and commands like exec. RouterOS lost track of that order during key renegotiation (rekeying) triggered before authentication finished. The session state stopped matching reality, and the system began handling messages that belonged to a later protocol phase. An unauthenticated client could open a channel and send exec, which allowed creating, overwriting, and reconstructing files.

CVE-2026-67281 is a different kind of problem, living in WebFig, specifically the /jsproxy component. It combines two issues. The first is an uninitialized pointer (CWE-824): a newly allocated session structure could inherit a leftover memory region from a previous object, including a stale pointer to permission data. The second is a classic path traversal in how URIs are parsed. Together they allowed unauthenticated reads of root-owned files, well outside the sandbox WebFig is supposed to operate in.

The third case, CVE-2026-67277, affects the bandwidth-test service and is itself a bundle of smaller bugs. A linked btest connection could reach the test-handling phase before the parent session finished authenticating. On top of that, buffer initialization was incomplete: some bytes went out over the network without being overwritten first, so fragments of kernel memory leaked along with the test packet. A separate bug in packet length validation, an integer underflow on an unsigned value, could turn a very small number into a very large one and crash the device.

The last of the four, CVE-2026-67278, sits on the certificate side of things. RSA PKCS#1 v1.5 signature verification in the X.509 implementation was too permissive. It didn’t rigorously check the full structure of the decoded block: padding, separator, algorithm identifier, and hash. With a key using a small public exponent, such as e = 3, it was possible to craft a value that passed the check despite not being a valid signature. As a result, RouterOS could accept a certificate that no trusted authority actually signed. On its own this doesn’t open access to the router, but it undermines the integrity of TLS verification wherever RouterOS is the one checking the other side’s certificate.

Why this is more than a routine security bulletin

Six CVEs in one advisory isn’t unusual by itself. What’s unusual is that they touch nearly every core security mechanism at once: authentication, authorization, protocol state, file isolation, memory management, and cryptographic validation. In several places, RouterOS made security decisions based on data that was never properly verified. And where the bugs live in SSH, they can be chained. That’s exactly why MikroTrick made the list of things to patch immediately rather than at the next convenient maintenance window.

The attacks are already happening

CERT Polska confirmed active exploitation against RouterOS devices with SSH reachable from the public internet. The observed campaign used an account named ops, and among the attacking sources CERT identified the IP addresses 82.192.72.4 and 103.102.31.18. Logs worth checking for include entries like login failure for user -2 from <ip> via ssh and user <name> added by ssh:-2@<ip>. These are indicators from one observed campaign, not a complete list of possible traces. Their absence proves nothing.

Which versions are affected

The issue affects RouterOS 7.24 below 7.24.2, the 7.x branch below 7.23.4, and 6.x below 6.49.21. Fixes are available in 7.24.2 Stable, 7.23.4 Long-term, and 6.49.21 Long-term, and later releases. For the 7.23 branch, MikroTik has also shipped 7.23.5, which on top of the security fixes resolves an IPv6 DHCP issue introduced back in 7.23.4.

Patching is only the first step

If a device was ever exposed to the internet, installing the update doesn’t close the case. You still need to check whether someone got to it first. Newer RouterOS versions include a built-in mechanism that flags some known signs of unauthorized tampering. Check the status with /system/device-mode/print and watch specifically for flagged: yes. That said, it’s a signal, not a verdict. The absence of the flag doesn’t automatically mean the device is clean. It’s worth reviewing users, scripts, the scheduler, proxy configuration, VPN tunnels, firewall rules, NAT, and routing while you’re at it.

Reducing the risk going forward

RouterOS admin services, meaning SSH, WinBox, WWW, and WWW-SSL, shouldn’t sit directly on the internet with no restrictions. It makes far more sense to route that traffic through a VPN, a dedicated management segment, or a tightly limited set of source IPs. There’s also something teams tend to skip: centralized log collection. If a router gets modified or wiped later, the event history still survives on the other side.

How BOIT can help

In our day-to-day network audits, we regularly find edge routers that have sat for years with default configuration and open administrative access. MikroTik is no exception here. We can inventory the MikroTik devices on your network, check RouterOS versions and how exposed the admin services are, then carry out the update and verify the configuration afterward.

If you suspect a device may already have been targeted, we can run a deeper review covering users, scripts, the scheduler, VPN, routing, firewall, and NAT configuration. We also go beyond patching: we help redesign how network devices are managed, so edge equipment, usually the most privileged point in the whole infrastructure, isn’t left exposed to the next incident like this one.

Sources:

Bartłomiej Ożóg

Spis treści