CVE-2026-67276 (CVSS 9.2): The “MikroTrick” SSH Auth Bypass Is Hijacking MikroTik Routers Without a Password — Patch RouterOS Now

Millions of routers. Six new vulnerabilities. One working exploit chain. And attackers were already inside before the patch dropped.

On 3 September 2026, MikroTik quietly pushed firmware updates across every RouterOS release branch. The reason — buried in a terse one-paragraph advisory — was a cluster of six vulnerabilities discovered and coordinated by CERT Polska. Two of those flaws can be chained to seize full administrative control of any MikroTik device with its SSH service reachable from the internet — no password required. By the time patches were available, attackers had already been exploiting the chain for at least 24 hours. If you run MikroTik in your environment, assume that any internet-exposed device is now under active threat.

Why MikroTik Is Everywhere — Especially in India

MikroTik’s RouterOS powers an enormous slice of the world’s network infrastructure. The Latvian vendor’s hardware is the backbone of thousands of Indian Internet Service Providers, WISP networks, enterprise branch offices, and managed service provider stacks — particularly in Tier-2 and Tier-3 cities where cost-effective, feature-rich routing is critical. From a CHR instance in a cloud VPC to a CCR2004 anchoring a 10-Gbps uplink, MikroTik is rarely missing from a network diagram in South Asia.

That ubiquity is precisely what makes this vulnerability cluster so alarming. Shodan and Censys scans routinely surface hundreds of thousands of internet-facing RouterOS devices globally, with SSH (port 22) and Winbox (port 8291) openly accessible. In India alone, tens of thousands of RouterOS instances are reachable directly from the internet — many of them ISP core routers or enterprise gateways that, if compromised, could affect thousands of downstream users simultaneously.

The MikroTrick Attack Chain: A Technical Breakdown

CERT Polska disclosed six vulnerabilities in total, but the critical threat stems from chaining two of them in sequence. Here is how the MikroTrick exploit works in practice:

Stage 1 — CVE-2026-67276: SSH Authentication Bypass (CVSS 9.2)

RouterOS’s SSH daemon failed to properly verify RSA public keys during the authentication handshake. Under normal circumstances, SSH public-key authentication requires an attacker to possess the private portion of a key to prove identity. CVE-2026-67276 breaks that guarantee: if an attacker knows (or can enumerate) a valid username and the public portion of that user’s RSA key — both of which may be leaked through various means including Winbox or API exposure — they can craft a fraudulent key pair that the RouterOS SSH daemon accepts as valid. The attacker logs in without ever possessing the private key. No brute force. No credential stuffing. Just a crafted authentication packet.

Stage 2 — CVE-2026-86060: SSH Privilege Escalation

Once authenticated as any user (even a restricted account), the attacker exploits improper handling of malformed usernames within the SSH session mechanism. By supplying a username containing disallowed characters at a specific stage of the SSH negotiation, the attacker triggers an elevation path that grants full administrative (superadmin) privileges. Combined with Stage 1, the result is unauthenticated root-level access to the device — remote code execution, full configuration control, and persistent access with no password ever exchanged.

Post-Exploitation Behaviour Observed in the Wild

Security researchers and CERT Polska have documented the following attacker actions on compromised routers:

• Creation of a backdoor user account named “ops”
• Installation of unauthorized SSH public keys for persistent re-entry
• Modification of firewall rules to open additional access paths
• Enablement of proxy and tunnelling services (traffic interception)
• Deployment of malicious scripts including ftpsrv.py, launch.sh, and serve.py

MikroTrick: Vulnerability & Patch Summary

CVE	CVSS	Type	Patched In
CVE-2026-67276	9.2	SSH Auth Bypass (RSA key flaw)	6.49.21 / 7.23.5 / 7.24.2 / 7.25beta3
CVE-2026-86060	9.2	SSH Privilege Escalation	6.49.21 / 7.23.5 / 7.24.2 / 7.25beta3
CVE-2026-67277	8.8	Bandwidth-test memory disclosure & DoS	6.49.21 / 7.23.5 / 7.24.2 / 7.25beta3
+ 3 additional vulnerabilities not yet fully disclosed by MikroTik

Timeline: Exploit Before Patch

What makes MikroTrick particularly troubling is the timeline. Exploitation started before MikroTik had a chance to ship patches — a classic zero-day scenario where defenders had a window of exactly zero:

• 2 September 2026: Active exploitation begins. Attack traffic originates from IPs 82.192.72.4 (Leaseweb, Netherlands) and 103.102.31.18. Compromised devices show “ops” account creation and the telltale ssh:-2@<IP> log pattern.
• 3 September 2026: MikroTik releases patches across all supported release channels. Official advisory published at mikrotik.com/supportsec — deliberately sparse on technical detail to slow weaponisation.
• 5 September 2026: Security researcher Costin Raiu publishes a detailed technical breakdown, and CERT Polska releases its full coordinated disclosure. Despite MikroTik’s best efforts to withhold attack mechanics, exploitation had already accelerated.
• 6 September 2026: CISA issues advisory ICSA-26-209-05; The Hacker News and international media confirm widespread active exploitation.

Indicators of Compromise: Is Your Router Already Owned?

If your MikroTik devices have had SSH exposed to the internet — even temporarily — you must assume compromise until proven otherwise. Here is what to look for:

• Log entries: Search system logs for the string ssh:-2@. This is the distinctive fingerprint of a successful MikroTrick authentication. Run: /log print where message~"ssh:-2"
• Rogue users: Check for accounts named “ops” or any unfamiliar user. Run: /user print
• Flagged status: Run /system/device-mode/print and look for a “Flagged” marker — RouterOS’s built-in post-patch tamper indicator.
• Firewall anomalies: Review all firewall rules added after 2 September 2026 for unexpected accept rules on management ports.
• Unknown scripts: Run /system script print and examine any unrecognised automation.
• SSH keys: Audit all authorized keys under /user ssh-keys print for keys you did not add.
• Block attacker IPs: Add firewall drop rules for 82.192.72.4 and 103.102.31.18 as a temporary measure.

What You Should Do Right Now: Sanjay Seth’s Defence Playbook

Having spent three decades managing enterprise and ISP-grade networks across India — including large-scale MikroTik deployments — here is my prioritised response checklist:

1. Patch Immediately — This Is Not Optional

Log into every RouterOS device and run Check for Updates (System → Packages → Check For Updates) or push via Winbox/SSH. Target versions:

• RouterOS 6 (legacy): 6.49.21
• RouterOS 7 Long-Term: 7.23.5
• RouterOS 7 Stable: 7.24.2
• RouterOS 7 Development: 7.25beta3

Use The Dude or a custom Ansible/SSH script to audit version compliance across your entire MikroTik fleet within the next two hours.

2. Restrict Management Services — The Zero-Trust Way

Even after patching, management services should never be internet-exposed. Apply an IP Services allowlist immediately:

• Set SSH, Winbox, and the API to accept connections from trusted management IPs only
• Disable the bandwidth-test server (/tool bandwidth-server set enabled=no) — it is unnecessary on edge devices and was implicated in CVE-2026-67277
• Disable Winbox and the REST API if your workflow does not require them
• Place management access behind a dedicated out-of-band management VLAN or a FortiGate-controlled zero-trust access segment

This principle aligns directly with FortiGate SD-WAN best practices for secure management plane segregation — management traffic should never share a path with production data plane traffic.

3. Incident Response for Compromised Devices

If your logs confirm compromise, do not simply patch and continue. A patched-but-backdoored router is still fully compromised:

1. Isolate the device from the network immediately
2. Preserve logs: export /log print to a remote syslog server before any action
3. Factory reset — do not restore from a backup taken after 2 September; the backup may contain attacker modifications
4. Reconfigure from a known-good baseline (pre-September config or a freshly hardened template)
5. Report the incident to CERT-In (cert-in.org.in) if the device is part of critical infrastructure under India’s IT Act obligations

4. Threat-Informed Monitoring Going Forward

Add these to your SIEM/syslog correlation rules permanently:

• Alert on any SSH login from a non-whitelisted IP to any network device
• Alert on user account creation events in RouterOS (/system history entries with “user added”)
• Alert on firewall rule changes outside change-management windows
• Review the broader APT tradecraft in how the Fire Ant APT group exploited Cisco IOS XR devices — the post-exploitation playbook is remarkably similar, and the lessons apply directly to any network operating system.

The Broader Network Device Security Picture

MikroTrick is not an isolated incident — it is part of an accelerating pattern. Nation-state and criminal threat actors have made network operating systems a priority target precisely because they sit at the intersection of high privilege, low EDR coverage, and persistent connectivity. A compromised router is a perfect long-term surveillance platform: it sees every packet, can redirect DNS, intercept credentials in transit, and maintain tunnelled access indefinitely.

The recent unauthenticated RCE in Cisco Nexus 9000 and the Citrix NetScaler authentication bypass are symptoms of the same disease: management planes left exposed, patching cycles measured in weeks rather than hours, and a systematic under-investment in network device security posture. The answer is a zero-trust management architecture — assume that any exposed management interface is a vulnerability waiting to be exploited, regardless of vendor or firmware version.

Frequently Asked Questions

Is my MikroTik device at risk if SSH is not exposed to the internet?

The MikroTrick chain requires direct SSH access from the attacker’s IP. If your device is behind NAT, has SSH disabled, or has SSH restricted to a trusted management network with firewall rules, the primary attack vector is blocked. However, you should still patch immediately — the other four undisclosed vulnerabilities may have different access requirements, and your device could be reached via lateral movement from another compromised internal host.

My RouterOS says “Flagged” after the update — what does that mean?

RouterOS added a tamper-detection mechanism that marks devices as “Flagged” if it detects signs of pre-patch compromise during the update process. A Flagged status means MikroTik’s firmware believes your device was accessed by attackers before the patch was applied. Follow MikroTik’s Flagged Status documentation, isolate the device, collect forensic evidence, and rebuild from a clean baseline.

Can a VPN or firewall in front of the MikroTik device provide sufficient protection?

Yes — if the firewall policy correctly blocks all direct internet access to the RouterOS management interfaces (SSH port 22, Winbox port 8291, API port 8728/8729, HTTP/HTTPS). This is the recommended architecture: place a FortiGate or equivalent NGFW in front of all MikroTik management access and enforce strict allowlisting. The firewall, however, must be fully patched itself — a chain is only as strong as its weakest link.

How quickly should I patch if my MikroTik is only in internal network segments?

Still within 24–48 hours. Internal-only devices are not safe from lateral movement — if any device on your network is compromised (a laptop, a server, a DMZ host), an attacker can pivot to internal MikroTik devices. Given the severity and the fact that exploit code is now circulating publicly, treat this as a Priority 1 patching event regardless of device exposure level.

---

The MikroTrick attack chain is a stark reminder that network devices are the new endpoint — and they need the same disciplined patch management, access control rigour, and continuous monitoring that you apply to servers and workstations. If you have MikroTik in your environment, stop reading and start patching. Once your fleet is secure, reach out to discuss a comprehensive network security posture review.