On September 10, 2026, CISA added CVE-2026-67277 to the Known Exploited Vulnerabilities (KEV) catalog — which means this is not a theoretical risk. Threat actors are actively exploiting a missing authentication for critical function vulnerability in MikroTik RouterOS's btest (bandwidth test) service right now, achieving kernel memory disclosure and denial of service against exposed devices.
If you operate MikroTik routers — and given MikroTik's prevalence in ISP, WISP, MSP, and branch-office deployments, a great many organizations do, sometimes without realizing it — this demands immediate attention. MikroTik devices have historically been a favorite target for botnet operators and nation-state actors precisely because they sit at the network edge, often run outdated firmware, and are rarely covered by enterprise EDR. A kernel memory disclosure primitive on a perimeter router is not a nuisance; it is a foothold for credential theft, configuration extraction, traffic interception, and follow-on compromise of everything behind the device.
Under CISA's Binding Operational Directive (BOD) 26-04, federal civilian agencies are required to remediate on an accelerated timeline, and CISA's accompanying "Forensics Triage Requirements" mandate evidence preservation before remediation where compromise is suspected. Every private-sector organization should treat this with the same urgency.
Technical Analysis
Affected Component
The vulnerability resides in the btest service — RouterOS's built-in bandwidth-test server (/tool bandwidth-server), which listens on TCP/UDP port 2000 and is used to measure throughput between MikroTik devices. The flaw is classified as CWE-306: Missing Authentication for Critical Function. In practical terms, the btest service fails to properly authenticate requests before invoking a privileged code path, allowing a remote, unauthenticated attacker to:
- Disclose kernel memory — leaking sensitive in-memory data from the router, which can include credentials, session material, routing table contents, and fragments of forwarded traffic.
- Trigger denial of service — crashing or destabilizing the device, taking down whatever network segments depend on it.
Exploitation Requirements and Attack Chain (Defender's View)
- Authentication: None required. Any host that can reach UDP/TCP 2000 on the RouterOS device can attempt exploitation.
- Exposure surface: The highest-risk population is devices with the btest service reachable from the internet — which happens far more often than it should due to permissive default firewall configurations, port-forwarding mistakes, and management interfaces left on WAN-facing addresses. Laterally reachable internal devices are also at risk once an attacker has any internal foothold.
- Observable exploitation behavior: Defenders should expect to see connection attempts to port 2000 from sources outside the small set of legitimate bandwidth-testing peers, malformed or high-volume btest sessions, device instability or unexpected reboots following such traffic, and — where memory disclosure succeeds — follow-on authentication attempts using harvested credentials.
Exploitation Status
- CISA KEV listed: Yes — added 2026-09-10.
- Active exploitation: Confirmed by CISA. KEV inclusion is only made on the basis of reliable evidence of exploitation in the wild.
- CISA required action: Apply vendor mitigations; comply with BOD 26-04 prioritization guidance and CISA's Forensics Triage Requirements; for cloud services follow applicable BOD 26-04 guidance, or discontinue use of the product if mitigations are unavailable. Asset owners are explicitly responsible for evaluating each device's internet exposure.
Detection & Response
The honest reality: RouterOS devices themselves generate limited telemetry, so detection has to happen at the network layer and in your log pipeline. The highest-fidelity signals are (1) any connection to TCP/UDP 2000 from an unauthorized source, and (2) RouterOS syslog evidence of service crashes or unexpected reboots temporally correlated with that traffic. Baseline your legitimate btest peers first — in most environments that list is empty or near-empty, which makes this a low-noise detection.
---
title: Unauthorized Connection to MikroTik btest Service (Port 2000)
id: 9b2e7d41-3c6a-4f18-b2d5-7a1c9e4f8d02
status: experimental
description: Detects network connections to TCP/UDP port 2000, the MikroTik RouterOS bandwidth-test (btest) service, associated with active exploitation of CVE-2026-67277 (missing authentication, kernel memory disclosure, DoS). Tune the allowed-source filter to your legitimate btest peers; in most environments no host should be initiating these connections at all.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-67277
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/10
tags:
- attack.initial_access
- attack.t1190
- attack.t1046
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort: 2000
filter_legitimate:
Initiated: 'false'
condition: selection and not filter_legitimate
falsepositives:
- Legitimate bandwidth testing between managed MikroTik peers (allowlist known peer IPs)
level: high
---
title: MikroTik RouterOS Crash or Unexpected Reboot via Syslog
id: 4f8a1c96-2d7b-4e53-a9c1-6b3d8f2e7a15
status: experimental
description: Detects RouterOS syslog signatures of device crashes, kernel faults, and unexpected reboots that may follow denial-of-service exploitation of the btest service (CVE-2026-67277). Correlate with inbound port 2000 traffic for high-confidence alerting.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-67277
- https://attack.mitre.org/techniques/T1499/
author: Security Arsenal
date: 2026/09/10
tags:
- attack.impact
- attack.t1499
logsource:
product: linux
service: syslog
detection:
selection:
- 'router rebooted'
- 'kernel failure'
- 'critical error'
- 'system,error,critical'
- 'unexpected shutdown'
condition: selection
falsepositives:
- Planned maintenance reboots; power events. Enrich with change tickets before escalating.
level: medium
// Hunt: Connections to MikroTik btest service (TCP/UDP 2000) — CVE-2026-67277
// Works against firewall/NDR logs ingested via CEF (CommonSecurityLog) and Defender network events.
let Lookback = 14d;
let LegitBtestPeers = dynamic(["10.10.0.5", "10.10.0.6"]); // replace with approved btest peer IPs, or leave empty
let SuspiciousToBtest =
union isfuzzy=true
(CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DestinationPort == 2000
| where not(SourceIP in (LegitBtestPeers))
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, Protocol, DeviceAction, SourceHostName),
(DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where RemotePort == 2000
| where not(RemoteIP in (LegitBtestPeers))
| project TimeGenerated, SourceIP=LocalIP, DestinationIP=RemoteIP, DestinationPort=RemotePort, Protocol, DeviceAction=ActionType, SourceHostName=DeviceName);
SuspiciousToBtest
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Attempts=count(), Sources=dcount(SourceIP)
by DestinationIP, DestinationPort, Protocol
| order by Attempts desc;
// Correlation: MikroTik crash/reboot syslog events within 1 hour of inbound btest traffic — CVE-2026-67277 DoS indicator
let Lookback = 14d;
let BtestHits =
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DestinationPort == 2000
| summarize by DestinationIP, bin(TimeGenerated, 1h);
Syslog
| where TimeGenerated > ago(Lookback)
| where SyslogMessage has_any ("router rebooted", "kernel failure", "system,error,critical", "unexpected shutdown")
| extend DestinationIP = HostIP, HourBucket = bin(TimeGenerated, 1h)
| join kind=inner (BtestHits) on DestinationIP, $left.HourBucket == $right.TimeGenerated
| project TimeGenerated, HostIP, Facility, SeverityLevel, SyslogMessage
| order by TimeGenerated desc;
-- Artifact: SecurityArsenal.Network.BtestConnections
-- Hunt for established or attempted connections to MikroTik btest service (port 2000)
-- from managed endpoints. Any hit outside an approved peer list warrants triage of the
-- target router for CVE-2026-67277 exploitation (memory disclosure / DoS).
LET connections <= SELECT Pid, Name, Path, Status,
Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE RemotePort = 2000
SELECT *, timestamp(epoch=now()) AS CollectionTime
FROM connections
#!/usr/bin/env bash
# cve-2026-67277-audit.sh — Audit MikroTik estate for btest exposure and apply mitigations
# Run from a management jump host with SSH access to RouterOS devices and nmap installed.
set -euo pipefail
TARGETS_FILE="mikrotik_hosts.txt" # one router IP per line
SSH_USER="readonly-audit" # use a least-privilege audit account
SCAN_SUBNET="192.0.2.0/24" # adjust to your environment
echo "=== [1/4] Scanning for devices exposing btest (TCP/UDP 2000) ==="
nmap -Pn -sS -sU -p 2000 --open "${SCAN_SUBNET}" -oG btest_exposed.gnmap
grep "Ports: 2000" btest_exposed.gnmap | awk '{print $2}' | sort -u > btest_exposed_ips.txt
echo "Exposed hosts:"; cat btest_exposed_ips.txt
echo "=== [2/4] Pulling RouterOS version and bandwidth-server state per device ==="
while read -r HOST; do
echo "--- ${HOST} ---"
ssh -o ConnectTimeout=8 -o StrictHostKeyChecking=accept-new "${SSH_USER}@${HOST}" \
"/system resource print; /tool bandwidth-server print; /log print where topics~\"critical\"" \
|| echo "WARN: SSH to ${HOST} failed"
done < "${TARGETS_FILE}"
echo "=== [3/4] MITIGATION (run interactively per device after reviewing output above) ==="
cat <<'EOF'
# On each RouterOS device — disable the btest service outright (safest if unused):
/tool bandwidth-server set enabled=no
# If bandwidth testing is operationally required, restrict to authorized peers only:
/tool bandwidth-server set enabled=yes authenticate=yes
/ip firewall filter add chain=input protocol=tcp dst-port=2000 \
src-address-list=btest-allowed action=accept comment="CVE-2026-67277 allow peers"
/ip firewall filter add chain=input protocol=udp dst-port=2000 \
src-address-list=btest-allowed action=accept comment="CVE-2026-67277 allow peers"
/ip firewall filter add chain=input dst-port=2000 action=drop comment="CVE-2026-67277 drop btest"
/ip firewall address-list add list=btest-allowed address=10.10.0.5 comment="approved peer"
# Confirm no management/btest services are WAN-reachable and apply vendor fix:
/ip service print
/system package update check-for-updates # then install per vendor advisory
EOF
echo "=== [4/4] Preserve forensic evidence BEFORE reboot/patch if compromise suspected ==="
echo "Per CISA Forensics Triage Requirements: export logs and config first:"
echo " ssh ${SSH_USER}@<host> \"/log print file=prepatch-log; /export file=prepatch-config\""
echo " scp ${SSH_USER}@<host>:prepatch-log.txt ${SSH_USER}@<host>:prepatch-config.rsc ./evidence/"
Remediation
Treat this as a KEV-driven emergency change, not a routine patch cycle.
-
Inventory and exposure assessment (today). Enumerate every RouterOS device in your estate — including ISP-managed CPE and forgotten branch units. Determine which are internet-reachable on port 2000 using external scanning, not just internal assumptions. CISA's KEV entry explicitly places this responsibility on asset owners.
-
Apply vendor mitigations. Follow the official MikroTik advisory referenced in the CISA KEV entry and upgrade to the fixed RouterOS release for your train (long-term/stable). Pull the advisory and packages only from mikrotik.com. If your device model is end-of-support and no fixed release exists, CISA's directive is unambiguous: discontinue use of the product.
-
Disable the btest service where not required.
/tool bandwidth-server set enabled=noeliminates the attack surface entirely. In our experience, the vast majority of deployments never legitimately use bandwidth-server. -
Where btest is required, fence it. Enforce authentication, and add input-chain firewall rules restricting TCP/UDP 2000 to a named address list of authorized peers, as shown in the script above. Never expose it on a WAN-facing interface.
-
Forensics triage before remediation where exposure existed. Per CISA's Forensics Triage Requirements referenced in the KEV entry: if a device was internet-exposed on port 2000, preserve logs, configuration exports, and volatile state before patching or rebooting. Look for evidence of prior exploitation — unexpected reboots, unknown user accounts, modified configurations, unfamiliar scheduler scripts, and outbound connections from the router itself. RouterOS persistence via scheduler and scripts is a well-worn attacker technique; a patch does not evict an established implant.
-
Credential rotation. Given the kernel memory disclosure primitive, rotate any credentials that transited or were stored on potentially exposed devices: RouterOS local accounts, PPPoE secrets, SNMP communities, VPN pre-shared keys, and API credentials.
-
Verify and monitor. Post-remediation, re-scan externally to confirm port 2000 is closed or filtered, deploy the detection content above into your SIEM, and forward RouterOS syslog centrally — if your MikroTik fleet isn't logging to your SOC today, that gap is itself a finding.
Federal civilian agencies must remediate per the BOD 26-04 deadline attached to this KEV entry; private-sector organizations should hold themselves to the same standard given confirmed in-the-wild exploitation.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.