A prohibited leading character in a RouterOS username rewrites the session's policy mask

The policy mask is what a RouterOS session is permitted to do once its login has been accepted ^[5]. According to the NVD description quoted in a dev.to writeup by Jeffrey Ciend, the SSH login path mishandles arguments when a username begins with a prohibited character, and the trusted policy mask can be changed. The entry classes that as privilege escalation ^[3]. Nothing is corrupted in memory ^[4]. The parse runs inside the authentication path, and its output is the authorization the device applies for the rest of the session ^[4].

The second bug is an ordering failure. RouterOS admits a "related" btest connection before the corresponding primary session has completed authentication ^[8]. An unauthenticated client can use that state to start an IPv4 UDP test, and with `random-data=false` the sender transmits an uninitialized tail from a kernel packet buffer ^[9]. btest is MikroTik's bandwidth-testing service ^[10]. Reading leftover kernel buffer bytes is an odd way to measure throughput. The writeup's own reading is that a UDP test session is not administrative access by itself, and that what it demonstrates is an unauthenticated code path reaching a network-facing service ^[11].

Two sentences in the same writeup point at different attacker preconditions. It says neither description requires the attacker to break cryptography or guess a credential ^[12]. It also says the practical effect of the escalation is that a low-privilege or restricted account becomes an administrative one ^[6]. The base scores are given as 9.8 and 8.2, with no vector strings ^[2][7][23]. Anyone scoping this internally should pull the vector from NVD before writing off devices that have no restricted accounts.

ZoomEye indexes 8,083,155 assets matching `os="RouterOS"` ^[14]. For that to be the number of devices at risk from these two CVEs, every fingerprinted box would have to be running an unfixed version and answering SSH or btest from an untrusted network. The index filters on neither ^[15]. That makes 8,083,155 a ceiling on the affected population ^[16].

Upgrading fixes both ^[17]. MikroTik keeps parallel stable and long-term branches, so the correct target version depends on which branch a deployment follows ^[18]. The writeup tells operators to confirm the fixed version from the vendor advisory for their branch instead of taking a number from a secondary source ^[19].

Exposure is the part that outlives the patch cycle, and the argument for treating it as its own line item is that the next authentication-path flaw arrives at the same internet-facing management services ^[20]. The configuration positions are specific: SSH on port 22 should not be reachable from the internet on an edge router, administrative interfaces belong on a management network or behind a controlled access path, and btest should be disabled unless it is actively in use ^[21]. Detection is the awkward part. The escalation changes the policy mask, so an intrusion may not produce a failed-login pattern, and the review that follows is an audit for unexpected accounts ^[22]. In my view the SSH decision is the one to make this week. The version bump only covers your branch, and closing SSH and btest to untrusted networks also covers the next authentication-path flaw.