CVE-2026-67276

SSH user impersonation possible in Mikrotik RouterOS

No known exploitation. EPSS puts it in the 28th percentile. A vendor fix is available.

CVSS 3.18.1High EPSS percentile28th0.4% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known FixVendor fixNo build named by the sources

Published 2026-09-05Updated 2026-09-25Sources: CVE.org, NVD

NVD CVE.org

What to do

The vendor has published a fix. Version details are below where the sources state them.

Steps

Written by AI from the record

Check your RouterOS version in the RouterOS UI (or via your existing management tooling).
If you are on RouterOS 7.x, upgrade to 7.24.2 (Stable) or 7.23.4 (Long-term) as your fixed release.
Review whether SSH access is reachable from the internet; restrict it to trusted IPs/VPN only.
After upgrading, verify SSH login behavior and confirm that only intended users can access the router remotely.

Usually a quick update

Check it yourselfA free OpenVAS check exists for this CVE. Run it against your hosts.Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

RouterOS does not compare the complete RSA public key when matching an SSH authentication request to an authorized user key, checking the key type and modulus but omitting the exponent. Because signature verification uses the client-supplied key, an attacker knowing an authorized RSA modulus can supply a key with exponent one, forge a valid signature, and open an SSH command channel as the target user without the private key.This issue affects only 7.x branch was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable)

In plain language

Written by AI from the record

In some MikroTik RouterOS versions, an attacker may be able to log in as another SSH user; if you expose RouterOS SSH to the internet, this is serious and you should update to 7.24.2 or 7.23.4.

CVE-2026-67276 is an SSH authentication flaw in MikroTik RouterOS where the server does not fully match the authorized RSA public key parameters (not comparing the complete key, omitting the exponent), enabling SSH user impersonation via forged authentication for an SSH session as another user; fixed in RouterOS 7.24.2 and 7.23.4.

If you're affected

Unauthorized router configuration changes
Service disruption for internet access
Traffic interception or rerouting
Device takeover under a real user

What is it

This vulnerability is like having a bouncer who checks only part of an ID. With the right information, someone might be able to pass the check and start an SSH session as a different authorized user, without that user’s private key.

Who is affected

This matters if you run MikroTik RouterOS and allow remote administration using SSH (especially from anywhere on the internet). If your SSH management is reachable by attackers, this could let them impersonate another user account and take control of router functions. The risk depends on whether the vulnerable RouterOS 7.x SSH service is reachable from where an attacker can attempt authentication (e.g., internet-facing or insufficiently restricted access).

How urgent is it

This is a RED issue because it targets SSH login, which is a common path for taking over network devices. Even though no public exploit code is known, the flaw is specific enough to enable real impersonation, so you should treat it as an active, high-impact authentication risk. Update to the fixed RouterOS versions immediately to close the impersonation path.

What to do — in detail

Confirm exposure
- Identify which RouterOS version you run.
  - In RouterOS: check System/Packages or the system “version” readout.
- Determine whether SSH is enabled.
- Determine where SSH is reachable from.
  - Check firewall/routing rules and whether port 22 is accessible from untrusted networks (for example, the public internet).
Decide if you are affected
- This issue is described as affecting the 7.x branch, with fixes provided for:
  - RouterOS fixed in 7.23.4 (Long-term)
  - RouterOS fixed in 7.24.2 (Stable)
- If you are on RouterOS 7.x and not at or above the fixed versions, plan to upgrade.
Upgrade to the fixed release
- Upgrade to one of the fixed versions (choose based on your operational preference):
  - Stable: 7.24.2
  - Long-term: 7.23.4
- During the upgrade window, ensure you have console/onsite access or out-of-band management available in case the device needs recovery.
Temporary mitigation if you can’t upgrade right away
- Restrict SSH access to trusted IP addresses only (or require a VPN/bastion host).
- Block inbound SSH from the internet where possible.
- The goal is to make the vulnerable authentication path unreachable from untrusted sources.
Validate after patching
- Re-check RouterOS version to confirm it updated successfully.
- Attempt SSH login only as expected users from trusted networks.
- Review authentication-related logs/events (where available) for unexpected attempts.
What to monitor
- Continued SSH connection attempts from unusual sources (even after restricting access).
- Router configuration changes occurring outside your normal change process.

CISA/KEV timing note

This CVE is not listed in the CISA KEV set per the provided findings.

Technical context

Severity/impact model: An SSH server in MikroTik RouterOS can allow impersonation of an authorized user during SSH authentication. The weakness is a public-key matching/verification mismatch: RouterOS does not compare the complete RSA public key when mapping an authentication attempt to an authorized key, omitting the exponent. An attacker who can identify a valid authorized RSA modulus can craft an authentication using a different RSA exponent, enabling forged signature verification and establishing an SSH command channel as the target user.

Attack vector: Network-based SSH authentication. This is relevant where SSH access to the RouterOS device is reachable and the attacker can attempt authentication.

Exploitation status: Not listed in CISA KEV and no public exploit code is on record in the provided findings. However, the traffic-light verdict is RED, and the described mechanism directly enables user impersonation.

Fix: RouterOS 7.x fixed in 7.24.2 (Stable) and 7.23.4 (Long-term).

EPSS: Provided as a prediction (0.2%, flat trend), but KEV/news exploitation confirmation would override such predictions; no KEV entry is provided here.

KEV meaning in this context: CISA KEV lists vulnerabilities known to be exploited; this one is not currently listed.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS28th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.4% chance of exploitation activity in the next 30 days, which ranks it in the 28th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Attention now

Sustained, driven by in-the-wild reports.

Lifecycle

12 events over 20 days, from the signal feeds we watch.

2026-09-25Patch availableworkaround available, record updated
2026-09-21Analysis publishedMikroTik's Newest Router Bugs Were Found by an AI Model. Its Last Two KEV Listings Fueled the Mēris Botnet.
2026-09-09Record updated
2026-09-08Record updated
2026-09-07Record updated
2026-09-05OpenVAS check addedpublished, weakness classified, att&ck mapped, record updated

Affected products

Mikrotikcommercial · LVaka routeros, winbox
- RouterOSNetwork DeviceOn-premNetworking Infrastructure / router-switch

And 1 more affected product. See all after sign-in

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Scored 8.1 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity HighRequires specific conditions like a race condition or non-default configuration
Privileges Required NoneNo authentication required — anyone can exploit this
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability HighTotal denial of service — the component is completely unavailable