CVE-2026-67277: MikroTik RouterOS Missing Authentication in btest Service Allows Kernel Memory Disclosure and DoS

Background

MikroTik RouterOS is the operating system powering MikroTik’s widely deployed line of routers, switches, and wireless access points, used across ISPs, enterprises, and small businesses for routing, firewalling, and network management. RouterOS ships with a bandwidth-testing utility, btest (BTest), which is used to measure throughput between two RouterOS devices or a RouterOS device and a compatible test client — a diagnostic feature intended for network administrators to validate link performance.

CVE-2026-67277 is a missing-authentication vulnerability in the btest service. Because btest is designed to respond to test requests from a counterpart device, it has historically exposed a network-facing service that doesn’t always enforce the same authentication rigor as RouterOS’s primary management interfaces (Winbox, SSH, HTTP/HTTPS API) — and this CVE confirms that gap can be abused well beyond its intended diagnostic purpose.

Technical Mechanism

CVE-2026-67277 is classified under CWE-306 (Missing Authentication for Critical Function). The vulnerability is in the btest service’s handling of incoming requests: a function that should require authentication — or at minimum, strict validation that distinguishes legitimate bandwidth-test traffic from arbitrary attacker-supplied input — does not enforce that control.

Based on the KEV description, the exploitation flow is:

1. An attacker with network reachability to a RouterOS device’s btest service (UDP/TCP port 2000, btest’s default) sends crafted requests to the service without presenting any credentials.
2. Because the service does not authenticate the request before processing it, the attacker-controlled input is processed directly by the btest handler running within the RouterOS kernel/userspace boundary.
3. The flaw allows two distinct outcomes from this unauthenticated access: kernel memory disclosure — the service returns data read from kernel memory that should not be exposed to the requester, likely due to an out-of-bounds read or buffer-handling flaw in how btest assembles its response — and denial of service, where malformed or excessive requests crash or hang the btest process or the broader RouterOS networking stack.
4. Because no authentication gate exists, any attacker who can route traffic to the device’s btest port — which may be reachable from the WAN interface on misconfigured or exposed deployments — can attempt both outcomes repeatedly.

The dual confidentiality (memory disclosure) and availability (DoS) impact from a single missing-authentication flaw is consistent with the CVSS 8.8 score: no privileges required, network-reachable, and meaningful impact across multiple CIA triad dimensions.

Real-World Exploitation Evidence

CISA added CVE-2026-67277 to the Known Exploited Vulnerabilities catalog on 10 September 2026, which confirms — by definition of KEV listing — that CISA has evidence of active exploitation in the wild rather than theoretical risk alone.

No specific threat actor, campaign, or intrusion set is named in the available KEV record for this entry. No specific threat actor has been publicly attributed to exploitation of this CVE; its KEV listing confirms active exploitation in the wild, but attribution detail is not yet public. MikroTik RouterOS devices have a long history of mass-exploitation by botnet operators (notably the Mēris and subsequent botnets built on misconfigured or vulnerable MikroTik fleets) given the sheer number of internet-exposed devices running the OS — this CVE fits a pattern that has historically attracted opportunistic, large-scale exploitation rather than narrowly targeted intrusions, though no such confirmation exists yet for this specific CVE.

The knownRansomwareCampaignUse field for this entry is marked “Unknown” — CISA has not confirmed ransomware use of this CVE at this time.

Impact Assessment

A missing-authentication flaw in a network device’s diagnostic service, with both memory-disclosure and DoS outcomes, carries meaningful risk:

• Confidentiality: Kernel memory disclosure can leak sensitive in-memory data — potentially including fragments of credentials, session tokens, cryptographic key material, or other process memory that happened to be adjacent to the disclosed region at the time of the request. The exact sensitivity of disclosed data depends on runtime memory layout and is difficult to bound precisely without vendor detail.
• Availability: The denial-of-service outcome can disrupt routing and connectivity for every device and network segment relying on the affected RouterOS device — for an ISP or enterprise edge router, this translates directly into an outage affecting all downstream users.
• Reconnaissance value: Even where memory disclosure alone does not yield immediately exploitable secrets, repeated exploitation can aid an attacker in fingerprinting internal memory layout or software versions to support follow-on attacks against the same device.

Sector-specific risk: MikroTik RouterOS devices are deployed heavily at the network edge — by ISPs for customer-premises equipment, by enterprises for branch routing, and by WISPs (wireless ISPs) for last-mile connectivity. A device sitting at the network edge that can be remotely crashed or have its kernel memory probed represents a disproportionately high-value target relative to an equivalent flaw in an internal-only service, since edge routers are both internet-exposed by design and critical to availability for every device behind them.

Affected Versions

MikroTik’s security advisory (linked below) is the authoritative source for the exact affected RouterOS version range. Organizations should consult it directly for the definitive list. In general terms:

Any RouterOS deployment running a version predating MikroTik’s September 2026 security advisory should be treated as presumptively vulnerable until confirmed patched.

Remediation Steps

CISA’s required action directs organizations to apply vendor mitigations per BOD 26-04 guidance, follow Forensics Triage Requirements, or discontinue use of the product if mitigations are unavailable.

1. Identify the RouterOS version running on all MikroTik devices in the environment:

/system resource print

2. Apply MikroTik’s security update referenced in the vendor advisory (see References) to bring all devices to a patched RouterOS version.

3. Disable the btest service if bandwidth testing is not actively required — this removes the vulnerable attack surface outright:

/tool bandwidth-test
# Disable the BTest server feature via Winbox/CLI if not in active use;
# ensure no firewall rule permits inbound access to the btest port (default UDP/TCP 2000) from untrusted interfaces

4. Restrict btest access at the firewall as a defense-in-depth measure even after patching — the service should never be reachable from the WAN or any untrusted interface:

/ip firewall filter add chain=input protocol=tcp dst-port=2000 in-interface=ether1-WAN action=drop
/ip firewall filter add chain=input protocol=udp dst-port=2000 in-interface=ether1-WAN action=drop

5. Audit all RouterOS devices for WAN-facing management/diagnostic service exposure generally — MikroTik’s historical mass-exploitation incidents have consistently involved unnecessarily exposed services on the WAN interface.

Detection Guidance

Exact signatures for btest exploitation attempts should be sourced from MikroTik’s advisory or network IDS vendor feeds, since granular exploitation details are not fully public. General detection approaches:

• Firewall/flow logs: Review for unexpected inbound connections to TCP/UDP port 2000 (btest default) from untrusted or internet-sourced addresses — any such traffic on an edge device warrants investigation.
• Device stability monitoring: Unexpected reboots, btest service crashes, or RouterOS kernel panics logged in /log print may indicate failed or successful denial-of-service exploitation attempts.
• Anomalous btest traffic volume: A sudden spike in btest-protocol requests from a small number of source addresses, outside of scheduled bandwidth-testing windows, is a plausible indicator of probing or exploitation.
• Baseline comparison: Organizations running scheduled, legitimate bandwidth tests should baseline normal btest traffic patterns so that anomalous volume or source diversity stands out more clearly in logs.

Timeline

References

• MikroTik Support — September 2026 Vulnerability Advisory
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA — BOD 26-04 Implementation Guidance: Forensics Triage Requirements
• NVD — CVE-2026-67277