CVE-2026-67277 and CVE-2026-86060: MikroTik RouterOS Missing Authentication Lets Unauthenticated Attackers Hit the btest Service and SSH Login Path

Both CVEs affect the same RouterOS version ranges. Per NVD's published configuration data, CVE-2026-67277 affects RouterOS 6.0.0 through 6.49.20, 7.0.0 through 7.23.3, and 7.24.0 through 7.24.1. CVE-2026-86060 affects the equivalent ranges: 6.0 up to (but not including) 6.49.21, 7.0 up to 7.23.4, and 7.24 up to 7.24.2. In practice, that covers effectively every RouterOS release in production before MikroTik's September 2026 disclosure.

Both vulnerabilities are fixed in the same three release branches: 6.49.21 on the long-term branch, 7.23.4 on the long-term branch, and 7.24.2 on the stable branch. MikroTik's own advisory also lists 7.25 beta 3 as carrying the fix on the development/testing branch, for organizations already tracking that pre-release line. There is no partial or configuration-only fix for either CVE; moving to one of these patched releases (matching your current branch) is the actual remediation.

The btest service itself, RouterOS's built-in bandwidth-testing tool, listens on UDP/TCP port 2000 by default and has historically been reachable from WAN-facing interfaces on devices where an administrator has not explicitly firewalled it off. Confirming whether that port is reachable from outside your network is the first exposure check described in the Validation section below.

CISA's September 10, 2026 catalog update, "CISA Adds Two Known Exploited Vulnerabilities to Catalog," added both CVE-2026-67277 and CVE-2026-86060 the same day, which is CISA's standing signal that it has evidence of active exploitation for a given CVE. That is a real, actionable confirmation, not a hypothetical risk rating.

Being precise about the evidence matters here. As of this writing, the KEV catalog listing and MikroTik's own September 2026 advisory are the two primary sources establishing this pair as real, current threats. MikroTik's advisory is notably thin on technical detail: it states directly that MikroTik is "not currently publishing detailed information" about the underlying flaws, and instead focuses on patched versions and post-upgrade device-inspection guidance (checking for unknown scripts, users, or configuration changes, and watching for a "Flagged" compromise indicator RouterOS itself can surface after upgrade). We did not find a named, independent third-party research writeup with its own observed exploitation telemetry specific to CVE-2026-67277 or CVE-2026-86060 in the same way some other KEV entries carry a named vendor research report.

This pair sits inside a broader MikroTik RouterOS disclosure batch from the same period that also includes CVE-2026-67276, CVE-2026-67278, and CVE-2026-67279, and CERT Polska has published its own summary covering that broader RouterOS vulnerability set. None of that changes the remediation priority: a CISA KEV listing on its own is sufficient justification to patch on an accelerated timeline, and the same disclosure batch is the reason to check your RouterOS version against all of the patched releases above, not just the two CVEs covered in this article. This kind of unauthenticated exposure on internet-facing edge gear is the same underlying pattern covered in CVE-2026-20079, the pre-auth root RCE in Cisco Secure FMC and in CVE-2026-19490, the Citrix NetScaler authentication bypass: perimeter management and control-plane services being the actual entry point, not a phishing lure.

We do not have hand-authored Sigma rules, vendor detect queries, or WAF rules for this specific CVE pair yet, so this section covers detection in prose rather than pointing to a ready-made rule set. Do not treat the absence of a published rule as an absence of a detection strategy; it means the strategy has to be built from what MikroTik and NVD have disclosed rather than pulled from an existing library.

For CVE-2026-67277, the exploitable behavior is network-visible: an unauthenticated client opening a btest session (typically on UDP/TCP port 2000) without the primary session having completed RouterOS authentication first. If your network monitoring or the router's own logging can distinguish an unauthenticated btest connection attempt from a normal, credentialed bandwidth test initiated by an administrator, that distinction is the detection signal. Repeated crash-and-restart events on a RouterOS device, particularly one with btest reachable from the WAN, are also worth correlating against this CVE given the kernel-restart impact NVD describes.

For CVE-2026-86060, the exploitable behavior happens during SSH authentication itself: a connecting client presenting a username that begins with a prohibited or unusual character as part of the login attempt, before authentication succeeds. SSH access logs or session records showing malformed or unusual usernames attempting to authenticate to RouterOS's SSH service are the closest available signal, keeping in mind that the flaw is in how the login helper parses the username, not in a later authenticated action.

Both of these are behavioral indicators inferred from the vendor's and NVD's own descriptions of the flaws, not confirmed IOCs or a published detection rule. Treat them as a starting point for building your own monitoring against RouterOS syslog or SSH logs, not as a substitute for patching.

Start by checking whether the btest service and SSH are reachable from outside your network. From an external vantage point, or using an internet-facing asset scan, confirm whether UDP/TCP port 2000 (btest) and your SSH port are open on your MikroTik device's WAN interface. If btest is not something your organization actively uses for bandwidth diagnostics, its reachability from the WAN is itself the exposure this CVE depends on, independent of whether you have patched yet.

Next, confirm your running RouterOS version. RouterOS reports its version directly in the WinBox or WebFig system information, or via the '/system resource print' command at the CLI. Compare that output against the fixed releases: 6.49.21, 7.23.4, or 7.24.2, depending on which branch you run. A version string that predates your branch's fixed release means both CVE-2026-67277 and CVE-2026-86060 apply to that device.

After upgrading, MikroTik's own advisory recommends inspecting the device for unknown scripts, unrecognized users, or configuration changes that were not made by your team, and checking whether RouterOS has flagged the device as compromised, a status MikroTik states the system can surface directly in logs after upgrade. Treat a flagged device as a signal to move to incident response rather than considering the upgrade itself sufficient remediation for that specific unit.

The vendor-published fix is the primary remediation for both CVEs: upgrade to 6.49.21, 7.23.4, or 7.24.2 depending on your current branch. MikroTik has not published a configuration-only workaround that fully closes either flaw short of the version upgrade.

Beyond the patch itself, CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," and its accompanying implementation guidance describe how federal agencies (and, as a practical model, any organization) should sequence remediation for KEV-listed vulnerabilities like this pair, prioritizing internet-facing, actively exploited flaws over routine patch cycles. If your organization suspects a device has already been compromised, CISA's Forensics Triage Requirements describe the evidence-preservation and investigation steps to follow before assuming a simple reboot or upgrade resolves the incident. If no mitigation is deployable for a given device (for example, hardware that can no longer run a patched RouterOS release), CISA's guidance is direct: discontinue use of that product. Each organization is responsible for evaluating its own asset's actual internet exposure; this article's port-2000 and SSH reachability check in the Validation section above is the starting point for that evaluation, not a substitute for it.

The most consequential limitation for this specific pair is that MikroTik's own advisory withholds technical detail. MikroTik states directly that it is "not currently publishing detailed information" about how either flaw actually works beyond what NVD's CVE descriptions cover, which is why this article's Detection section is built from behavioral inference rather than a vendor-confirmed indicator list. Re-check MikroTik's advisory page periodically; if the company publishes a fuller technical writeup later, treat it as the authoritative update to the detection guidance above.

A related and equally practical gap: the broader MikroTik RouterOS disclosure batch this pair belongs to also includes CVE-2026-67276, which has its own named public proof-of-concept ("MikroTrick") covered by independent researchers, distinct from CVE-2026-67277 and CVE-2026-86060 covered in this article. Do not assume patching only these two CVEs closes out this disclosure round; check your RouterOS version against MikroTik's full September 2026 advisory, not just the two CVE numbers in this post's title.

The active-exploitation evidence for both CVEs currently traces to CISA's KEV catalog addition and MikroTik's own advisory; we did not find a named third-party research report with independently observed exploitation telemetry specific to CVE-2026-67277 or CVE-2026-86060 as of this writing. CERT Polska has published a summary covering the broader RouterOS vulnerability batch, which is worth checking for updates, but a KEV listing on its own remains sufficient grounds to prioritize patching regardless of how many independent parties eventually publish their own observations.

Finally, this post does not include Sigma rules, vendor-specific detect or hunt queries, or WAF rules, because none exist yet in our system for this specific threat. If that changes, an updated version of this article will carry them; until then, the prose guidance in the Detection section above is the best available starting point.