MikroTrick: The MikroTik RouterOS SSH Bypass That Was Being Exploited Before the Patch Even Shipped

An RSA public key has two numbers that actually matter: a modulus and an exponent. RouterOS, the operating system running on millions of MikroTik routers, only bothered checking one of them when you logged in over SSH with a key. That single omission is the entire reason a router with no username, no password, and no prior foothold of any kind could be handed over to a stranger on the internet, and it's why CERT Polska's researchers gave the resulting attack chain a name of its own: MikroTrick.

I've managed MikroTik hardware at ISP points of presence and branch sites where it earns its keep precisely because it's cheap, capable, and easy to leave running for years without anyone touching it. That last part is the problem. A router nobody has logged into since 2022 is also a router nobody has patched since 2022, and MikroTrick is a sharp reminder of what that quiet neglect costs.

What MikroTrick Actually Is

MikroTrick isn't one bug, it's two, tracked as CVE-2026-67276 and CVE-2026-86060, both scored CVSS 9.2, that chain together into full unauthenticated administrative control of a device whenever its SSH service is reachable from an untrusted network.

CVE-2026-67276 — SSH authentication bypass

When a user authenticates to RouterOS over SSH using a public key instead of a password, the server is supposed to verify that the key presented matches the full public key on file for that account. RouterOS instead compared only the key type and the RSA modulus, and did not validate the exponent as part of that match. Security researchers who reverse-engineered the patch diff describe a practical consequence of that gap: an attacker who already knows (or can obtain) the modulus of a legitimate user's authorized key can construct a completely different key pair that shares that modulus, using a trivial exponent, forge a valid signature with the private half of their own forged key, and get authenticated as that user, without ever touching the real private key.

That's the bypass. No password guessing, no credential theft, no phishing. Just a router that only checked half of a key it should have checked in full.

CVE-2026-86060 — privilege escalation via a crafted username

The second half of the chain is a separate flaw in how RouterOS handles SSH usernames that begin with a disallowed character. By crafting a username in a specific malformed way, an attacker manipulates the resulting session into carrying full administrative privileges, regardless of which account was actually being impersonated in the first place.

Individually, each bug is bad. Chained together, they add up to an attacker with no credentials landing a root-equivalent session on your router, using nothing but network reachability to port 22 (or whatever port SSH is bound to).

The Kill Chain, Step by Step

Recon. The attacker identifies a MikroTik device with SSH reachable from the internet and enumerates or guesses a valid local username, RouterOS's default admin account being an obvious first guess on unhardened devices.
Obtain the modulus. The attacker needs the RSA modulus of that user's authorized key. Exactly how this is sourced varies by target (leaked keys, misconfigured key management, or values obtainable during the handshake itself), but it does not require the private key.
Forge a matching key (CVE-2026-67276). The attacker builds a new key pair sharing the target's modulus, with an exponent chosen to keep signing trivial, and presents it during SSH authentication. RouterOS's incomplete validation accepts it as a match.
Authenticate as the victim user. The attacker now holds a session under that user's identity, without ever possessing their real private key.
Escalate via crafted username (CVE-2026-86060). By combining this with the malformed-username handling bug, the attacker's session is elevated to full administrative privileges, independent of what the impersonated account was actually permitted to do.
Full control. From here the attacker can create new privileged accounts, plant scripts and scheduled tasks, rewrite firewall rules to open further access, intercept or redirect traffic passing through the device, or use it as a proxy into whatever network sits behind it.
Observed in the wild: CERT Polska traced confirmed successful compromises, including creation of a new administrative account, to a single IP, 82.192.72.4, active since at least September 2, 2026. A second address, 103.102.31.18, was seen attempting the same chain without confirmed success.

The Timeline Is the Part That Should Worry You

Here's the detail that makes MikroTrick more than just another critical CVE pair. CERT Polska's telemetry shows exploitation beginning September 2, 2026. MikroTik shipped patched builds across every release channel, 7.25beta3, 7.24.2, 7.23.4, and 6.49.21, one day later, on September 3, 2026. CERT Polska's own public advisory didn't go out until September 5, 2026, once active exploitation had been independently confirmed.

MikroTik deliberately withheld technical detail in its initial advisory, hoping to buy administrators time to patch before anyone could reverse-engineer the fix. It didn't work. Independent researchers and forum users had reconstructed the mechanics from the patched binaries within days, and by the time CERT Polska published its full write-up, the attack was already confirmed live. Withholding detail slowed down write-ups like this one; it didn't slow down the people who already had the binaries to diff.

One more operational note worth flagging for anyone planning an upgrade: the 7.23.4 release that carries this fix introduced a regression affecting IPv6 DHCP. A follow-up release, 7.23.5, retains the security fix while resolving that regression, so long-term-channel users should target 7.23.5, not stop at 7.23.4.

Indicators of compromise

Indicator	What it means
`login failure for user -2 from <ip> via ssh`	Log signature left by an attempted MikroTrick authentication attempt
`user <name> added by ssh:-2@<ip>`	Log signature left when a new account is created via the exploited session
Account named `ops`	The specific rogue admin account CERT Polska observed attackers creating in confirmed compromises
`82.192.72.4`	Source IP tied to confirmed successful compromises since at least Sept 2, 2026
`103.102.31.18`	Source IP observed attempting the chain without confirmed success

One MikroTik administrator posting on the MikroTik subreddit described an unauthorized "ops" account appearing on their device around September 2 at 08:00 UTC, traced back to the same 82.192.72.4 address CERT Polska later confirmed — and, notably, chose a full factory reinstall rather than trust RouterOS's own built-in compromise detection to declare the device clean.

How Big Is the Exposed Surface?

The Shadowserver Foundation's scan on September 5, 2026 found approximately 122,500 MikroTik devices with SSH reachable from the internet. That number counts SSH exposure alone, not confirmed vulnerable firmware versions, so it's an upper bound on the immediately reachable attack surface rather than a confirmed victim count. For context, a broad Shodan query for internet-facing MikroTik RouterOS instances across all services commonly returns figures well north of 400,000, which tells you most exposed MikroTik boxes aren't running SSH publicly, but a large minority clearly are.

Branch	Affected versions	Fixed in
RouterOS 6 (legacy)	6.0.0 up to (not including) 6.49.21	6.49.21
RouterOS 7 (long-term)	7.0.0 up to (not including) 7.23.4	7.23.4 (target 7.23.5 due to IPv6 DHCP regression)
RouterOS 7 (stable)	7.24 up to (not including) 7.24.2	7.24.2
RouterOS 7 (development)	Not specified by CERT Polska	7.25beta3

It's worth saying plainly: MikroTik ships with SSH, WebFig, and the bandwidth-test service blocked from the WAN by default. Every one of those 122,500 exposed devices got that way because someone, an ISP, a managed service provider, or an administrator managing branch routers remotely, deliberately opened SSH to the world for convenience. That's an extremely common pattern in exactly the deployments where MikroTik shines: cheap CPE at scale, managed centrally, by a small team that doesn't want to run a jump host for every site.

The Other Bugs Riding Along

MikroTik's September patch round fixed six vulnerabilities total, not just the two that make up MikroTrick. The most notable of the rest is CVE-2026-67277 (CVSS 8.8), a flaw in the bandwidth-test service that let an unauthenticated connection reach a state that should only be reachable post-login. Combined with a separate leak of uninitialized packet-buffer data and an integer underflow in a size check, this could expose kernel memory or crash the device into a reboot. Three lower-severity fixes also went out, touching the SSH client, X.509 certificate handling, and the WebFig interface; CERT Polska deliberately withheld technical detail on those three to avoid handing attackers a roadmap.

How This Was Found: AI-Assisted Vulnerability Research, for Real This Time

The backstory here is worth a section on its own. CERT Polska researcher Sławomir Rozbicki found these vulnerabilities using OpenAI's GPT-5.5-cyber and GPT-5.6-sol models, through the team's access to OpenAI's Government and Trust Agency Collaboration (GTAC) program. This wasn't a single prompt producing a working exploit. CERT Polska built an isolated lab of MikroTik hardware, documented the system architecture, and set rules for safe test execution; the models then automated machine setup and teardown, version comparison, RFC and binary analysis, and the construction of scripts to confirm candidate bugs. Modeling the SSH handshake as a state machine and systematically testing what happens when a step is skipped, repeated, or reordered turned out to be a particularly effective technique for surfacing exactly this kind of validation gap.

Every hypothesis the models generated still needed confirmation on real hardware, negative-control testing, repetition on a clean machine, and a human impact assessment before anything went to MikroTik. CERT Polska is explicit that the models accelerated hypothesis generation and code analysis; they did not replace the human judgment needed to separate a real, exploitable bug from a false lead.

My Take

What strikes me most about MikroTrick isn't the CVSS score, it's the modulus-only check. That is such a specific, narrow shortcut to have taken in an SSH implementation that's been in production for years, on a product whose entire pitch to ISPs and network engineers is that it's a serious, capable piece of infrastructure software. Partial key validation is the kind of corner-cutting that looks completely fine in code review, right up until someone builds the exact key that satisfies your incomplete check. I've seen the same failure mode in other places over the years, config validation that checks a prefix but not a full value, an ACL that matches on subnet but forgets to check the interface, and it always reads the same way in hindsight: a check that was "good enough" until someone went looking for exactly what it wasn't checking.

The one-day gap between exploitation starting and the patch shipping is the other thing that sticks with me. This wasn't a slow-burn n-day where defenders had weeks of advance notice before opportunistic scanning picked up. Whoever found and weaponized this either independently discovered the same modulus-validation gap CERT Polska did, or got there by diffing an early build, and they had a working exploit before the vendor had a fix out the door. That's an uncomfortable data point for anyone who treats "wait for the patch, then patch" as an adequate cadence for internet-facing edge devices. By the time the patch exists, in cases like this one, you may already be behind.

And I don't think the AI-assisted discovery angle is a side note here, either. CERT Polska's own framing is careful and honest: the models didn't hand them an exploit on a plate, they accelerated the grinding work of hypothesis generation and binary comparison inside a lab a human team built and supervised. That's a legitimate, positive use of the technology, and it's good that a national CSIRT got there first. But the same acceleration is available to people with worse intentions, and the realistic expectation for the next few years is that the rate at which critical bugs surface in mature, widely deployed network gear is going to keep climbing, not level off. Patch cadence and exposure hygiene stop being periodic housekeeping tasks under that model; they become the baseline cost of running edge infrastructure at all.

What You Should Do Right Now

Patch today, not at the next maintenance window. Upgrade to 6.49.21, 7.23.5 (not 7.23.4, due to the IPv6 DHCP regression), 7.24.2, or later, via /system package update check-for-updates, /system package update download, then /system reboot, or through Winbox/WebFig's Check for Updates menu.
Audit exactly what's exposed before you assume you're fine. Run /ip service print and check which services are bound to which interfaces. If SSH, WWW/WWW-SSL, or the bandwidth-test server are reachable from a WAN interface, that's your actual attack surface, regardless of what you assumed your firewall rules did.
If you can't patch immediately, pull SSH off the WAN now. Restrict SSH, WebFig, and bandwidth-test to a trusted management network or VPN, or disable them outright if you don't actively need them exposed. Also avoid using the router's own /system ssh or /system ssh-exec client, or initiating outbound TLS, from an unpatched device toward untrusted hosts; the affected SSH client and X.509 code are reachable from that direction too.
Put remote management behind a VPN, permanently, not just as a stopgap. WireGuard is built into RouterOS and cheap to stand up. If your team is exposing SSH directly to the internet for convenience across a fleet of branch or customer-premises routers, that convenience is exactly the exposure MikroTrick depends on.
After patching, check for prior compromise, don't assume a clean bill of health. Run /system/device-mode/print and look for a "Flagged" status, then search logs for the IoCs above and for any account named ops. Critically: the absence of the Flagged marker does not prove the device is clean, MikroTik and CERT Polska are both explicit that this detection only catches selected known traces.
If you find signs of compromise, don't just clean it up in place. Isolate the device, preserve logs and configuration for analysis before touching anything, then factory reset and rebuild from a trusted, verified configuration source, not a backup taken from the compromised device itself. Rotate every password, key, and secret that device had access to, and report the incident to your national or sector CSIRT.

This article was researched and drafted with AI assistance as part of an experiment in building a faster tech-writing workflow, then reviewed and edited before publishing.

Primary source: MikroTrick (CVE-2026-67276 & CVE-2026-86060): MikroTik RouterOS Hijacking Is Already Underway — insomnisec, September 8, 2026

Secondary sources: Critical vulnerabilities in MikroTik RouterOS are being actively exploited — CERT Polska, September 5, 2026; CVE-2026-67276: MikroTik RouterOS SSH Zero-Day — SOC Prime