MikroTrick: The Three-CVE Chain That Silently Hands Attackers Admin Access to Your MikroTik Router

On September 10, 2026, CISA quietly added two MikroTik RouterOS flaws to its Known Exploited Vulnerabilities catalog — but by then, attackers had already been exploiting them for over a week. The vulnerability chain, dubbed “MikroTrick” by CERT Polska, lets any attacker on the internet walk straight into your MikroTik router with full administrator access. No password required. No credentials needed. If your RouterOS device has SSH exposed and it’s running an unpatched version, it is almost certainly already in someone else’s inventory.

MikroTik hardware powers a significant portion of India’s ISP infrastructure, enterprise branch networks, and wireless internet service providers. The brand’s affordability and capability made it ubiquitous — and that same ubiquity now makes CVE-2026-67276, CVE-2026-86060, and CVE-2026-67277 an emergency for IT teams across the country.

How MikroTrick Works: A Three-Step Unauthenticated Root Chain

CERT Polska named this exploit chain “MikroTrick” for a reason — it is elegant in its brutality. The attack chains three flaws into a seamless path from zero to full router ownership, and it does so without requiring any stolen credentials.

Step 1 — The SSH Authentication Bypass (CVE-2026-67276)

RouterOS performs RSA public-key authentication by validating an incoming client’s key against the key on file for the target user. The flaw: the check only compares the key type and modulus — it never verifies the exponent. An attacker who can identify a valid username and obtain (or guess) that user’s RSA modulus — obtainable from any previously-captured SSH handshake or from a public server if the device ever authenticated outbound — can construct a keypair with exponent e=1. The router accepts it as a valid authentication. The attacker now has a live SSH session as that user, authenticated to nothing more than mathematical trivia.

Step 2 — Privilege Escalation to Full Admin (CVE-2026-86060, CVSS 9.2)

Once inside, the attacker is not content with a restricted user account. CVE-2026-86060 is a flaw in how RouterOS processes SSH session usernames. Crafting an SSH username that begins with a disallowed character -2 triggers an argument-parsing error in RouterOS’s policy engine, and instead of rejecting the session, the router falls back to its administrative policy mask — giving the attacker full administrator privileges in a single step. This is why security researchers’ honeypots consistently see a new privileged user named ops created moments after exploitation: the attacker escalated instantly and created a persistence backdoor.

Step 3 — Parallel Unauthenticated Denial of Service (CVE-2026-67277, CVSS 8.8)

Even devices where SSH is restricted or the username-guessing requirement of CVE-2026-67276 proves difficult have a third exposure: the MikroTik bandwidth-test (btest) service. CVE-2026-67277 allows an unauthenticated connection to the btest daemon to trigger a state transition normally reserved for authenticated users. Combined with an integer underflow in packet-buffer size validation, this can expose kernel memory contents or crash the device into a forced reboot — no login, no username, no credentials of any kind required.

The Scale: 122,500 Devices, Two Known Attacker IPs

Shadowserver’s global scan on September 5, 2026, counted approximately 122,500 MikroTik RouterOS devices with SSH accessible from the open internet. These are devices that satisfy the single prerequisite for the full MikroTrick chain: reachable SSH port. The vulnerable population is the subset running pre-patch RouterOS builds — an unknown but large percentage given that RouterOS updates are manual and many network operators do not monitor firmware advisories.

Active exploitation was traced to two IP addresses: 82.192.72.4 (active from at least September 2, 2026 — one day before patches were released) and 103.102.31.18 (used in subsequent exploitation attempts). The September 2 activity means adversaries had working exploit code before MikroTik published a fix, suggesting either a zero-day window or advance knowledge of the vulnerability through other means.

CVE	CVSS	Component	Auth Required	Impact
CVE-2026-67276	TBD	SSH daemon	None	Pre-auth SSH login bypass
CVE-2026-86060	9.2	SSH username parser	Post-auth (exploits CVE-2026-67276)	Full admin escalation
CVE-2026-67277	8.8	Bandwidth-test service	None	DoS / kernel memory leak

Additional CVEs in the same disclosure batch — CVE-2026-67278, CVE-2026-67279, CVE-2026-67281 — address related parsing and memory-handling issues in RouterOS but were not confirmed as part of the active exploit chain.

Why This Matters for Indian Networks

MikroTik holds a commanding position in India’s networking infrastructure. Wireless internet service providers (WISPs) across tier-2 and tier-3 cities, enterprise branch offices, and managed service providers operating cost-sensitive networks have deployed MikroTik hardware at scale for over a decade. A compromised edge router is not merely a compromised router — it is a man-in-the-middle position on every packet flowing through it.

An attacker who owns your MikroTik router can intercept credentials, inject traffic, redirect DNS, pivot laterally into the LAN, and disable or misconfigure your firewall rules silently. In environments where the router is also handling VPN termination, SD-WAN routing, or MPLS transit, the blast radius extends across your entire connectivity fabric. This is exactly the threat model that PivotC2 RAT demonstrated against FortiGate firewalls — lateral movement from a compromised network device into the broader enterprise. The same playbook now applies to every unpatched MikroTik in your environment.

This attack also echoes the pre-auth RCE vulnerabilities that hit Check Point VPN firewalls earlier this month. The pattern is consistent: network perimeter devices are the most targeted category of hardware in 2026, and pre-authentication exploits are the most sought-after primitive.

Indicators of Compromise: What to Check Right Now

If you manage MikroTik hardware, run these checks before reading further:

• Unexplained user accounts — Log into RouterOS and run /user print. The presence of an account named ops or any account you did not create is a strong indicator of compromise.
• SSH log anomalies — Check /log print for authentication failures associated with the username -2. This is the telltale string left by the CVE-2026-86060 privilege-escalation attempt.
• Attacker IPs — Block and alert on 82.192.72.4 and 103.102.31.18 across your firewall logs.
• Unexpected firewall rule changes — Attackers frequently modify the MikroTik firewall to ensure persistent access. Audit your IP firewall rules against your known configuration baseline.
• New SSH keys — Run /ip ssh export-hostkey and compare against your known host key fingerprint.

What You Should Do: Sanjay Seth’s Zero-Trust Response Plan

From a zero-trust and defense-in-depth perspective, this vulnerability class demonstrates a fundamental principle: the network perimeter is not a trust boundary. Even if your edge router has not yet been compromised, the assumption that it is impenetrable has already been broken. Here is a concrete remediation and hardening plan:

1. Patch immediately — this is non-negotiable.
Update to RouterOS 6.49.21 (stable), 7.23.4 (stable-7), 7.24.2 (stable-7 latest), or 7.25beta3. In Winbox: go to System > Packages > Check For Updates. In the CLI: /system package update install. Verify the build number after reboot.

2. Disable SSH if you don’t need it.
If you manage MikroTik devices via Winbox, The Dude, or another mechanism, disable SSH entirely: /ip service disable ssh. If SSH is required, restrict it to a jump host or management IP via a firewall rule before the service processes the connection.

3. Firewall the SSH port at the perimeter.
Even if your device is patched, add an explicit firewall rule to drop SSH connections from any source not in your management CIDR. Run: /ip firewall filter add chain=input protocol=tcp dst-port=22 src-address-list=!management action=drop

4. Disable the bandwidth-test service.
Eliminate CVE-2026-67277’s attack vector by disabling the btest service if it is not operationally required: /tool bandwidth-server set enabled=no

5. Audit all user accounts and SSH keys.
Run /user print and /user ssh-keys print on every device. Remove any account or key that cannot be attributed to a known administrator.

6. Enable centralized logging.
Forward RouterOS logs to your SIEM or syslog server. Many compromised MikroTik devices go undetected simply because no one is reading the logs. Authentication events, firewall hits, and user modifications should generate alerts.

7. Treat every MikroTik as a zero-trust enforcement point, not a trusted perimeter.
Segment your networks such that a compromised edge router cannot reach your critical servers directly. Implement east-west firewall policies in your data centre and branch networks so that even if the router is owned, lateral movement is contained. This is the zero-trust network architecture principle — never trust the network, always verify the endpoint.

If you are running a FortiGate or other next-generation firewall behind your MikroTik devices, ensure your security policies are configured to inspect internal traffic — do not assume that traffic arriving from your edge router is inherently trusted.

AI in Vulnerability Discovery: A New Era

CERT Polska’s disclosure included a detail that deserves more attention than it received: the advisory credited AI models with assisting in the vulnerability discovery process. This is one of the first documented cases of a national CERT publicly acknowledging AI-assisted bug-finding in an official advisory. The implication is significant — if defenders are now using AI to find vulnerabilities faster, offensive actors are almost certainly doing the same. The window between vulnerability discovery and active exploitation is shrinking, and the September 2 attack activity — one day before patches were released — may be a harbinger of this acceleration.

Frequently Asked Questions

Do I need to be running SSH on port 22 to be affected by MikroTrick?

CVE-2026-67276 and CVE-2026-86060 require SSH to be accessible. The port number does not matter — if you moved SSH to a non-standard port, attackers can still reach it via a port scan. The only mitigation for these two CVEs is patching or disabling the SSH service entirely. CVE-2026-67277 affects the bandwidth-test service, which is a separate exposure on a different port (TCP 2000 by default).

My MikroTik device is behind a NAT gateway — am I protected?

If SSH and the btest service are not port-forwarded through your NAT device, you are not directly exposed to internet-sourced exploitation. However, you must still patch: an attacker who gains access to your LAN segment through any other vector (phishing, a compromised workstation, a separate vulnerability) can pivot to your MikroTik from inside. Also, many MikroTik deployments in India are directly internet-routable as edge devices — check your actual network topology before assuming NAT protection applies.

We’re running RouterOS 6.x, not 7.x — are we affected?

Yes. RouterOS 6.x is affected and is patched in build 6.49.21. If you are on an older 6.x branch (6.48.x, 6.47.x, etc.), upgrade to 6.49.21. Note that RouterOS 6 is approaching end-of-life; this is also an excellent opportunity to evaluate your migration path to RouterOS 7, which brings a more modern security architecture.

How do I confirm my device is running a patched build?

In the RouterOS CLI, run /system resource print and check the version field. You should see 6.49.21 (or higher), 7.23.4, 7.24.2, or 7.25beta3. In Winbox, the version is shown on the Dashboard screen immediately after login. If in doubt, run /system package update check-for-updates and compare.

Ready to Lock Down Your Network?

MikroTrick is another reminder that network infrastructure security is not a set-and-forget discipline. The devices connecting your branches, your users, and your data are as much an attack surface as your servers and endpoints — and in many cases, they are far less monitored. At P J Networks, Sanjay Seth and team have been hardening enterprise network infrastructure across India for over 30 years, from zero-trust architecture design to perimeter device audits and FortiGate/MikroTik security assessments.

If you are unsure whether your MikroTik devices are patched, whether your SSH exposure is under control, or whether your network segmentation would contain a compromised edge router, reach out for a security assessment. One conversation could be the difference between a patching exercise and an incident response engagement.