RouterOS SSH Flaw Is Under Active Attack
CERT Polska says attackers are chaining RouterOS flaws to seize internet-exposed devices; patch first, then investigate for compromise.
The 60-second version
CVE-2026-67276 lets an attacker impersonate an authorized RSA-key user on affected RouterOS 7 releases, and CERT Polska confirms it is part of an actively exploited takeover chain.
Key points
- The bug compares RSA key type and modulus but omits the exponent, while verification trusts client-supplied key parameters.
- The CVE record lists fixes in RouterOS 7.23.4 Long-term and 7.24.2 Stable; 6.49.21 addresses the broader disclosure, not this CVE specifically.
- Real-world full takeover is attributed to the two-flaw MikroTrick chain, so incident response must extend beyond installing the patch.
- Flagged status and known indicators help investigation, but their absence cannot prove a device is clean.
Verdict. Patch immediately, restrict management exposure, preserve evidence, inspect the configuration, and rebuild plus rotate secrets when compromise is suspected.
Immediate actionPatch first, then investigate
CERT Polska says attackers are actively exploiting a RouterOS vulnerability chain against devices whose SSH service is reachable from public networks. MikroTik has released fixed builds and recommends immediate upgrades.
Updating is only the first step. A device may already contain an unauthorized account, script, scheduled task, proxy, or tunnel. Preserve evidence and inspect the configuration after applying the fix.
MechanismHow an incomplete RSA comparison breaks SSH
An RSA public key is defined by a modulus and an exponent. Affected RouterOS releases matched an incoming key to an authorized key by checking its type and modulus, but omitted the exponent.
Because signature verification then used the client-supplied key, an attacker who knew a valid username and authorized RSA modulus could submit a different key with exponent one. That reduced the verification step to a form the attacker could satisfy without the private key and opened an SSH command channel as the targeted user.
A public key is not just its modulus. Ignoring one parameter allowed a different key to be treated as the authorized one.
ScopeThe version boundary needs careful reading
| RouterOS 7 Long-term | CVE-2026-67276 is fixed in 7.23.4; the CVE record identifies affected releases from 7.9 below that fixed branch. |
|---|---|
| RouterOS 7 Stable | CVE-2026-67276 is fixed in 7.24.2; releases from 7.24 below 7.24.2 are listed as affected. |
| RouterOS 7 Beta | MikroTik's broader September security bulletin lists 7.25 beta 3 as a fixed release. |
| RouterOS 6 Long-term | MikroTik lists 6.49.21 for the wider six-flaw disclosure, but the CVE-2026-67276 record says this specific issue affects only RouterOS 7. |
EvidenceWhat defenders should look for
CERT Polska reports a highly privileged account named ops in observed attacks and characteristic logs associated with users created through SSH. Fixed versions also scan for selected suspicious changes and may set RouterOS to Flagged status.
ResponseA defensible remediation sequence
- 1. Upgrade to the newest fixed release in the device's supported channel.
- 2. Until patching is complete, block SSH, WebFig and bandwidth-test access from untrusted networks; use a trusted management network or VPN.
- 3. Review logs and the Flagged value, then inspect users, scripts, scheduler tasks, proxies and tunnels for unrecognized entries.
- 4. If compromise is suspected, isolate the device and preserve logs and configuration before resetting it.
- 5. Rebuild from factory settings and a trusted configuration, then rotate passwords, keys and other secrets. Do not blindly restore a full backup from the suspect device.
The operational takeaway is simple: close the known path immediately, but treat previously exposed devices as potentially compromised until inspection supports a different conclusion.