MikroTik RouterOS SSH bug can let attackers hijack admin accounts

Published September 5, 2026 CVE-2026-67276

MikroTik router software called RouterOS has a bug in how it checks SSH logins. An attacker who knows part of an authorized user's public key can log in as that user over SSH without ever having their private key.

Severity
CriticalCVSS 4.0 · 9.2
Fix
Fixed in 7.24.2, 7.23.4Fix recorded 5 days ago
Affected versions
7.24 to before 7.24.2; 7.9 to before 7.23.4
Weakness
CWE-347Improper Verification of Cryptographic Signature
Exploit likelihood
0.24% in 30 daysEPSS, higher than 15% of known flaws
Affects
RouterOS
Exploited
Yes, in the wild

How it works

  • RouterOS checks an incoming SSH login key against the authorized keys stored for that user.
  • Doing this correctly requires checking both numbers in an RSA key: the modulus and the exponent.
  • RouterOS only checks the key type and the modulus, and skips the exponent entirely.
  • This lets an attacker who already knows a legitimate user's public modulus submit a different key, with a simple exponent value, that still passes RouterOS's incomplete check.
  • With that weaker check satisfied, a forged signature looks valid, so the attacker never needs the real private key.
  • The result is an SSH session opened as the impersonated user, with that user's normal permissions.

What to do

Check your installed RouterOS version in the router's System menu or WinBox. Versions 7.9 to before 7.23.4 and 7.24 to before 7.24.2 are affected, regardless of the selected update channel; RouterOS 6.x is not affected by this specific issue. Also check whether SSH is reachable from the internet, since CERT Polska reports this flaw has been combined with another one to fully compromise exposed devices. After updating, check the router's log and the output of /system device-mode print for a "Flagged" warning, which indicates a possible earlier compromise. Not seeing that warning does not prove the device was never accessed.

If you're on the Long-term channel, update to RouterOS 7.23.4 or later; if you're on Stable, update to 7.24.2 or later. Do this through MikroTik's normal "Check For Updates" process under System/Packages. This fixes the SSH key-check bug, but CERT Polska reports it was used together with another bug to fully compromise exposed routers, so after updating also review your configuration and logs for accounts, scripts, or scheduled tasks you don't recognize, and check MikroTik's security bulletin and "Flagged" status documentation for signs of an earlier compromise. Keeping SSH access limited to trusted networks or a VPN reduces exposure in the meantime but does not replace installing the update.

Technical details

An RSA public key consists of two numbers, a modulus and an exponent, and correct signature verification must use both. RouterOS's authorized-key matching logic checks only the key type and modulus, so an attacker who knows a legitimate user's modulus can submit a crafted key with a simple exponent and forge a valid-looking authentication signature without possessing the corresponding private key. This lets them open an SSH session and command channel as the impersonated user.

CVSS base score is 9.2, rated critical, and the flaw is tracked as CWE-347, improper verification of a cryptographic signature. CERT Polska reports this flaw has been combined with a separate SSH username-handling flaw (CVE-2026-86060) in real attacks to gain full administrative control of internet-exposed routers. This issue affects only the RouterOS 7.x branch; fixes shipped in 7.23.4 (Long-term) and 7.24.2 (Stable).

A parallel fix in 6.49.21 addresses other vulnerabilities found in the same research effort, not this one.

Severity breakdown

  • Attack vector Network Requires network access to the vulnerable service
  • Attack complexity High Attacker must bypass specific built-in protections
  • Required conditions None No particular deployment or execution condition is required
  • Privileges required None Attacker needs no account or login
  • User action None No action by another user is required
  • Vulnerable system: Data exposure High Sensitive data can be exposed with serious impact
  • Vulnerable system: Data changes High Protected data can be changed with serious impact
  • Vulnerable system: Service disruption High The service can stop or suffer serious disruption
  • Other systems: Data exposure None No additional impact beyond the vulnerable system
  • Other systems: Data changes None No additional impact beyond the vulnerable system
  • Other systems: Service disruption None No additional impact beyond the vulnerable system
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N Open in FIRST.org calculator

References

View Original Source