MikroTik RouterOS SSH argument injection enables privilege escalation

RouterOS contains an argument-handling flaw in the SSH login path involving usernames that begin with a prohibited character, allowing for the trusted RouterOS policy mask to be changed, leading to privilege escalation. Exploitation requires an unauthenticated SSH session to reach the RouterOS login helper. This issue was fixed in versions: 6.49.21 (Long-term), 7.23.4 (Long-term) and 7.24.2 (Stable).

MikroTik RouterOS is listed with a default status of unaffected, but the following branches are affected:

• 7.x branch: from 7.24 to less than 7.24.2.
• 7.x branch: from 7.0.0 to less than 7.23.4.
• 6.x branch: from 6.0.0 to less than 6.49.21.

CERT Polska identifies 6.49.21 in the Long-term channel, 7.23.4 in the Long-term channel, and 7.24.2 in the Stable channel as fixed versions. The status of parallel or other release branches is not inferred beyond these boundaries; MikroTik also lists 7.25 beta 3 among the releases containing fixes for this security update.

MikroTik RouterOS has a CWE-88 flaw in the SSH login path and login helper. The attacker controls the username input, and a username beginning with a prohibited character can be misinterpreted by the argument parser as special input rather than ordinary username data. This allows the trusted RouterOS policy mask to be changed, causing the resulting session to receive privileges beyond the original identity or group. CERT Polska describes the resulting session as having full administrative privileges in RouterOS. Exploitation requires access to the SSH service and an unauthenticated SSH session that reaches the login component; independent technical analysis indicates that the exact authentication condition may depend on the deployment's AAA or related configuration, so direct exploitability on every configuration has not been established.

The flaw is reachable over the network through the SSH service. The source record describes the prerequisite as an unauthenticated SSH session reaching the RouterOS login helper, while public technical analysis indicates that some deployments may still require an authentication or external AAA condition before the vulnerable path can be reached; this should be assessed against the actual configuration. No end-user interaction is identified, and the username is attacker-controlled input. CERT Polska has confirmed real-world attacks against RouterOS devices with SSH exposed to public networks, where an attack chain involving this issue was used to obtain administrative control. Public technical analysis and reproduction exist, but that does not establish that every RouterOS device exposing SSH is independently exploitable through this flaw without additional access conditions.

The flaw allows the SSH session's policy mask to be changed, resulting in escalation to full RouterOS administrative privileges. The technical impact can include modification of configuration, accounts, scripts, and other device controls, with the practical scope depending on the network functions performed by the router. When SSH is reachable from public networks, this issue can form part of an observed attack chain used to take control of routers. Available evidence does not establish that every device with exposed SSH is directly exploitable by this flaw alone without an authentication condition or another component in the chain.

• A compromised session can obtain full administrative privileges on RouterOS, enabling changes to device configuration and access controls.
• An attacker may create or modify privileged users, scripts, and other configuration elements; the specific consequences depend on the device's role in the network.
• The router's configuration integrity may be lost, and its services or network connectivity may be altered or disrupted.
• If the device was compromised, credentials, keys, and other secrets used on it should be treated as at risk and changed during incident response.

1. Update RouterOS to the fixed release for the deployed branch: 6.49.21 for Long-term v6, 7.23.4 for Long-term v7, or 7.24.2 for Stable. MikroTik also lists 7.25 beta 3 as containing the fix in this security update.
2. If immediate updating is not possible, disable SSH or restrict it to trusted management networks. Do not expose management ports to untrusted networks; use a management VPN instead of direct exposure where possible.
3. After updating, review the logs, the flagged status from /system/device-mode/print, unknown accounts, scripts, and other unrecognized configuration changes. Do not treat the absence of the flagged marker as proof that the device is safe.
4. If compromise indicators are present, isolate the device and preserve logs and configuration for analysis before resetting it. Restore only from a trusted configuration, reconfigure the device if necessary, rotate passwords, keys, and related secrets, and do not blindly restore a backup that may have been compromised.

• Inventory MikroTik RouterOS devices, record their versions, and determine whether SSH is reachable from untrusted networks.
• Review SSH logs for patterns such as login failure for user -2 from <ip> via ssh and user <name> added by ssh:-2@<ip>.
• Check for an unexpected highly privileged account named ops, as well as unknown users, scripts, scheduler tasks, or other unrecognized configuration changes.
• After updating, review compromise messages in the log and check the flagged value with /system/device-mode/print.
• Treat these artifacts as triggers for immediate investigation. Their absence does not prove that the device was not compromised.