CVE-2026-67276: MikroTik RouterOS 7 SSH public-key login without the private key

Critical 9.2 EPSS 8.9% MikroTik RouterOS

RouterOS 7 checks only the key type and modulus of an RSA public key, not the exponent, when matching an SSH login to a user's authorized key. An attacker who knows a user's name and RSA public key can forge a key and log in over SSH as that user without the private key. It affects RouterOS 7.9 up to the fixed releases 7.23.4 and 7.24.2 and only users with RSA keys in /user ssh-keys; RouterOS 6 is not listed as affected. Published with the September 2026 MikroTik advisory; CISA's enrichment listed no exploitation when it was published.

CVE-2026-67276CVE identifier
9.2CVSS 4.0 base score (critical)
8.9%EPSS: chance of exploitation in the next 30 days (higher than 95% of CVEs)
2026-09-05published

What do these terms mean? CVE · CVSS score · exploited (KEV) · EPSS · backported fix · all terms

What to do now

Check whether you run MikroTik RouterOS and which version (commands below).
Install the fixed version for your system: see “Patch it” below.
Installing a RouterOS update always reboots the router. On RouterBOARD hardware, run /system routerboard upgrade afterwards and reboot a second time so the matching RouterBOOT firmware is loaded. Plan for two short outages and make sure you have out-of-band or local access in case the router does not come back.
If you cannot patch today, apply the temporary mitigation below and patch as soon as possible.

Affected and fixed versions

Affected:

RouterOS 7.9 before 7.23.4
RouterOS 7.24 before 7.24.2

Fixed in:

RouterOS 7.23.4
RouterOS 7.24.2
Recommended as of 3 Nov 2026: 7.25 (stable) or 7.24.6 (long-term)

Am I affected?

/system resource print   # version, architecture-name, board-name
/system package update print   # channel, installed-version, latest-version
/system routerboard print   # current-firmware vs upgrade-firmware (not on CHR/x86)
/ip service print   # which management services are enabled, and from where
/user ssh-keys print   # users with RSA keys are the ones at risk; 7.25+ marks keys with a weak RSA exponent

Patch it

Use the commands for your system. Distribution packages often keep an older version number with the fix backported, so compare with the fixed package versions in the table below, not only with the upstream version.

Built from source

# RouterOS CLI (works on v6 and v7; v7 also accepts /system/package/update/...)
# Current releases as of 3 Nov 2026: 7.25 (stable), 7.24.6 (long-term), 6.49.23 (RouterOS 6)
/system backup save name=pre-update
/export file=pre-update
/system package update set channel=long-term   # or stable
/system package update check-for-updates
/system package update print   # status should say: New version is available
/system package update install   # downloads, installs and REBOOTS the router
# after it is back up:
/system resource print   # confirm the new version
/system routerboard upgrade   # RouterBOARD only: new RouterBOOT firmware
/system reboot   # REBOOTS again to load the firmware

General update steps for every system are on the Linux and Unix & BSD pages; after updating, see which services to restart.

If you cannot patch yet

Updating is the fix. Until you can update: disable SSH if you do not use it: /ip service disable ssh
Or allow SSH only from management addresses. RouterOS 7.24 and later: /ip service set ssh available-from=192.0.2.0/24 (older releases call the property address=). The port still answers, so also drop it in the firewall input chain.
Firewall input chain with an address list (put the rule before any rule that accepts the traffic): /ip firewall address-list add list=mgmt address=192.0.2.0/24 then /ip firewall filter add chain=input protocol=tcp dst-port=22,8291 src-address-list=!mgmt action=drop comment="mgmt only" place-before=0. Use Safe Mode (Ctrl+X in the CLI) so a mistake is rolled back if you lose the session.
Prefer a VPN such as WireGuard for remote management instead of exposing management ports (MikroTik, CERT Polska).
After updating, replace RSA keys with Ed25519 keys where your clients support it, and remove keys that are no longer needed (/user ssh-keys print, /user ssh-keys remove <number>).

Look for signs of exploitation

SSH logins for users with RSA keys from addresses you do not recognise (/log print where topics~"account").
Follow the same post-update checks as for CVE-2026-67279: unknown users, keys, scripts, scheduler entries, proxies and tunnels; /system device-mode print for the Flagged state.

Related vulnerabilities

Sources

Page generated automatically from official sources on 2026-11-03 18:05 UTC and reviewed by an editor. Always confirm with your vendor's advisory.