Unauthenticated bandwidth-test memory disclosure and kernel restart in MikroTik RouterOS

RouterOS accepts a "related" btest connection before the corresponding primary session has completed authentication. An unauthenticated client can use this state to start an IPv4 UDP test. With "random-data=false", the sender transmits an uninitialized tail from a kernel packet buffer. A separate unchecked, inverted packet-size interval causes unsigned integer underflow, anomalously large fragmented output, and can restart the RouterOS kernel. This issue was fixed in versions: 6.49.21 (Long-term), 7.23.4 (Long-term) and 7.24.2 (Stable)

The normalized record lists MikroTik RouterOS with a default status of unaffected, while the following ranges are identified as affected:

• The branch starting at 7.24 and below 7.24.2.
• The branch from 7.0.0 and below 7.23.4.
• The branch from 6.0.0 and below 6.49.21.

CERT Polska confirms the same branch boundaries. MikroTik lists the fix as included in 7.24.2, 7.23.4, 6.49.21, and 7.25 beta 3. The reviewed sources do not provide a complete mapping for every RouterOS branch outside those listed branches and fixed releases, so the status of unlisted branches should not be inferred.

MikroTik RouterOS accepts a related btest connection before the corresponding primary session has completed authentication. An unauthenticated client can therefore move the bandwidth-test service into a state that should only be reachable after login and start an IPv4 UDP test.

When random-data=false, the sender can transmit an uninitialized tail from a kernel packet buffer, exposing residual data held in kernel memory. A separate unchecked, inverted packet-size interval can cause unsigned integer underflow, anomalously large fragmented output, and a RouterOS kernel restart.

The public sources confirm the state-handling flaw, memory disclosure, and crash impact, but do not provide every packet-format detail or deployment condition needed to reproduce the issue. Practical exposure depends on whether the bandwidth-test server is reachable from an attacker-controlled or otherwise untrusted network.

The flaw is remotely reachable by an unauthenticated client and does not require user interaction. The important precondition is that the bandwidth-test server be reachable from an untrusted network; CERT Polska specifically recommends disabling or restricting access to that service as an attack-surface reduction measure.

The normalized record marks the issue as having a public exploit and as known exploited. CERT Polska also states that this CVE was added to the CISA Known Exploited Vulnerabilities Catalog and describes active exploitation in the context of attacks against RouterOS.

However, the full-control attacks observed by CERT Polska involved a multi-vulnerability RouterOS chain. The public evidence does not establish that every observed compromise used this bandwidth-test flaw alone, or that this flaw by itself grants administrative access.

The direct technical outcomes are two separate paths: disclosure of an uninitialized kernel packet-buffer tail and unsigned integer underflow during size validation, which can produce anomalous fragmented output or restart the RouterOS kernel.

The described security effect is limited confidentiality impact combined with high availability impact. The issue is not confirmed to permit data modification, account creation, privilege escalation, or administrative takeover when exploited on its own.

Operationally, a kernel restart can drop connections and interrupt services routed through the device. Memory disclosure may expose temporary kernel data, but the public sources do not establish exactly what data will be present in the transmitted buffer tail.

The issue can disclose a portion of residual data in kernel memory, but the available sources do not identify the specific data type or establish disclosure of complete configuration or credential stores.

Anomalously large fragmented output and a RouterOS kernel restart can interrupt traffic forwarding, device management, and network services that depend on the router. The confirmed direct impact is remote denial of service, not configuration modification or privilege escalation from this flaw alone.

If bandwidth-test is exposed to the Internet or another untrusted network, an unpatched device could become a source of service interruption without requiring a valid account. The practical effect depends on the device's role, redundancy, and the network scope it serves.

1. Upgrade RouterOS to the fixed release for the installed branch: use 6.49.21 for the affected branch from 6.0.0 and below 6.49.21, 7.23.4 for the branch from 7.0.0 and below 7.23.4, or 7.24.2 for the branch from 7.24 and below 7.24.2. MikroTik also lists 7.25 beta 3 as containing the fix.
2. If an upgrade cannot be applied immediately, disable the bandwidth-test server or block all access to it from outside trusted management networks. This is temporary risk reduction and does not replace installing a fixed RouterOS release.
3. After upgrading, check the logs for a device-compromise message, inspect the flagged value with /system/device-mode/print, and review users, scripts, scheduler tasks, proxy settings, tunnels, and other unrecognized configuration changes.
4. If compromise is suspected, isolate the device and preserve logs and configuration before resetting it. After the evidence is secured, restore from a trusted configuration, rebuild the device, and change relevant passwords, keys, and other secrets. Do not blindly restore a complete configuration backup created on a potentially compromised device.

1. Inventory all MikroTik RouterOS devices and compare their versions with the affected branches in affected_summary.
2. Determine whether the bandwidth-test server is enabled or reachable from the Internet or other untrusted networks. Exposure is a remediation priority, not proof that exploitation occurred.
3. Review logs and monitoring for unexpected RouterOS kernel or device restarts, especially when they coincide with externally sourced traffic to bandwidth-test. This is precautionary monitoring, not a confirmed IOC specific to this issue.
4. After upgrading, check for the device-compromise message in the log and inspect the flagged value with /system/device-mode/print. This mechanism detects only selected known traces, so an unflagged device is not proven safe.
5. Review users, scripts, scheduler tasks, proxy settings, tunnels, and other unrecognized configuration changes. If suspicious evidence is found, isolate the device and preserve logs and configuration before resetting or rebuilding it.