Two chained RouterOS flaws hand admin to an attacker who knows a username and a modulus

CERT Polska calls CVE-2026-67276 an SSH authentication bypass caused by incomplete RSA public key validation, and describes its effect as authenticating to the target account with a different RSA key, without holding the valid private key ^[2]. As a mechanism, the account lookup succeeds while the possession proof fails. That is why the stated precondition is the modulus of the registered key rather than the key itself ^[3]: the attacker needs to know which key the server expects, not to hold it. Moduli get handed out. That is what makes them public keys.

The second flaw takes a crafted username and returns full administrative privileges for the session ^[4]. The crafted value appears to survive into logging: both indicator strings CERT Polska publishes carry `-2` in the user field, one as `login failure for user -2` and one as `user <name> added by ssh:-2@<ip>` ^[6], which lines up with the reported next step of adding an administrative user ^[5]. Detection keys on the escalation artifact, the trail the bypass itself leaves behind in logs.

The fix list names four versions: 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 ^[8]. Three sit on RouterOS 7 branches and one on 6.49, and the newest of the four is a beta ^[14]. A fleet tracking 7.25 has one listed remedy, and it is that beta; the alternative is a branch move down to 7.24.2 ^[8][14]. Both are version decisions to be made across a fleet, and neither is a quick hotfix.

The hardening advice covers three services, SSH, WWW and Bandwidth Test, either disabled or restricted to management networks and allowed source IPs ^[11]. Two of the three map to a CVE named in the report, and the Bandwidth Test issue, CVE-2026-67277, is separate and has not been observed in this chain ^[12][15]. WWW is on that list for management surface reduction, not because it carries a named bug.

Patching closes the bypass, but the origin of the usernames and moduli stays unresolved, which CERT Polska records as unconfirmed ^[3]. The report does not claim the material was read off the devices, and it does not claim key reuse across fleets, so a specific leak path is not something the evidence supports yet. What the report does give is conditional: on suspected compromise, do not trust the configuration, preserve logs, factory reset and rebuild, and rotate all keys and credentials ^[9]. Two source IPs are published, 82.192.72.4 in successful cases and 103.102.31.18 in attempts, with the caveat that a match alone confirms nothing ^[10], and CERT Polska adds that an absence of flagged indicators does not guarantee the device is clean ^[7]. Those two properties together mean log triage can raise suspicion and cannot retire it, which puts every internet-reachable RouterOS box with thin logs in the rebuild column rather than the patch column ^[7][9].