RouterOS does not compare the complete RSA public key when matching an SSH authentication request to an…

CVE-2026-67276 is a cryptographic signature verification bypass in MikroTik RouterOS's SSH server, affecting all RouterOS 6.x before 6.49.21, all 7.x before 7.23.4 (long-term), and all 7.24.x before 7.24.2 (stable). When a client presents an RSA public key during SSH authentication, RouterOS matches it against the user's authorized keys by comparing only the key type and modulus — it ignores the public exponent entirely. Because signature verification uses the *client-supplied* key, an attacker who knows the modulus of any authorized RSA key can substitute exponent e=1. With e=1, signature verification computes sig^1 mod N = sig, meaning the attacker just sets the 'signature' equal to the expected padded hash. No private key is required. The attacker opens a full SSH command channel as the target user — typically admin. The same broken PKCS#1 v1.5 parsing also omitted padding-length checks and accepted trailing garbage, enabling a parallel Bleichenbacher-style e=3 cube-root forgery path independently discovered by researcher Nick Pratley.

The CERT-PL-assigned CVSS 4.0 score of 9.2 CRITICAL (AV:N/AC:H) is appropriate. The AC:H rating reflects the requirement that the attacker must already know the RSA modulus of an authorized key, which is a meaningful precondition — RSA public keys are by definition *public*, but the attacker must determine which specific key is authorized on the target device. In enterprise environments this friction is low: the same admin SSH key is routinely deployed across an entire fleet of managed MikroTik routers, and public keys are often discoverable in Git repos, config backups, or prior breach data. Combined with SSH being enabled by default on port 22, and hundreds of thousands of MikroTik devices being internet-facing per Shodan, the CRITICAL rating is warranted and we concur.

Why this verdict

• Unauthenticated network-reachable attack: The chain starts from the internet against SSH (enabled by default, port 22). No credentials, no user interaction, no prior foothold required — only knowledge of an authorized RSA public key modulus, which is by definition *public* information.
• Trivial weaponization: Setting e=1 reduces RSA signature verification to identity (sig^1 mod N = sig). The 'forgery' is just copying the expected hash into the signature field. A working PoC exists and weaponized tooling is days away at most.
• Role multiplier — network edge appliance, fleet-scale blast radius: MikroTik RouterOS is deployed as routers, firewalls, and VPN gateways. Compromise of a perimeter router yields traffic interception (BGP hijack, DNS poisoning, credential sniffing), lateral movement into every subnet behind it, and persistent backdoor access. ≥50% of RouterOS installations occupy this high-value role *by definition* — it's the product's primary purpose. With 500K–900K internet-facing devices per Shodan, the blast radius is massive. Verdict floor: CRITICAL.
• Enterprise key reuse amplifies reach: Organizations routinely deploy a single SSH admin key across their entire MikroTik fleet. Compromising one device's key list (or finding the key in a Git repo/config backup) unlocks every router in the fleet simultaneously.
• Minimal friction points: AC:H in the CVSS vector reflects needing the authorized key modulus, but this is a public value by design. The only real friction is whether the target uses RSA key auth (vs. password-only) and whether SSH is network-reachable — both conditions are met in a large share of deployments.

Why not higher?

CVSS 4.0 caps at 10.0 and this scores 9.2. The AC:H rating correctly reflects that the attacker must identify an authorized RSA modulus — not zero-click. There is no subsequent-system impact (SC/SI/SA:N), meaning the CVSS scope is limited to the router itself (though real-world blast radius extends to everything behind it). 9.2 is the appropriate ceiling.

Why not lower?

Downgrading below CRITICAL would require evidence that the exposure population or blast radius is narrow. Neither applies: 500K–900K internet-facing devices, SSH enabled by default, and the affected component IS the network perimeter. The 'need to know the RSA modulus' friction is negligible — RSA public keys are public by design and routinely reused across fleets. Password-only deployments are unaffected, but RSA key auth is standard practice for managed router fleets, which are exactly the high-value targets.

1. Restrict SSH access to management VLAN or VPN-only immediately — Use RouterOS /ip firewall filter or /ip service set ssh address=<mgmt-subnet> to block SSH from untrusted networks. This eliminates the network-reachable attack vector entirely. Per noisgate mitigation SLA for CRITICAL, deploy within 3 days.
2. Disable SSH and use Winbox with MAC-based or IP-restricted access — If SSH is not operationally required, disable it entirely (/ip service disable ssh). Winbox uses a different authentication path not affected by this CVE. Deploy within 3 days.
3. Rotate to Ed25519 or ECDSA SSH keys — The vulnerability only affects RSA key matching. Replace all RSA authorized keys with Ed25519 keys (/user ssh-keys import). This eliminates the attack surface even on unpatched devices. Prioritize within 3 days for internet-facing devices.
4. Audit for compromise indicators — On patched firmware (≥7.23.4, ≥6.49.21), check if the device is 'Flagged' status. On any version, inspect /system script, /user, /tool fetch, and /ip firewall for unauthorized entries. Run this audit on all MikroTik devices immediately.
5. Monitor SSH authentication logs for anomalous logins — Forward RouterOS logs to SIEM and alert on SSH public-key logins from unexpected source IPs. This provides detection-in-depth while patching proceeds.

Run this script from any Linux/macOS workstation that can reach the target MikroTik device on its SSH port. Requires ssh-keyscan (part of OpenSSH) and bash. No authentication needed. Usage: bash check_cve_2026_67276.sh <router-ip> [port]

#!/usr/bin/env bash
# CVE-2026-67276 checker — MikroTik RouterOS SSH RSA key exponent bypass
# Usage: bash check_cve_2026_67276.sh <host> [port]
# Requires: ssh-keyscan, bash 4+
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

HOST="${1:?Usage: $0 <host> [port]}"
PORT="${2:-22}"

# Step 1: grab the SSH banner to identify RouterOS version
BANNER=$(echo '' | timeout 5 nc -w3 "$HOST" "$PORT" 2>/dev/null | head -1 || true)

if [[ -z "$BANNER" ]]; then
  echo "UNKNOWN — could not connect to $HOST:$PORT"
  exit 2
fi

echo "Banner: $BANNER"

# RouterOS SSH banners look like: SSH-2.0-ROSSSH or include version info
if ! echo "$BANNER" | grep -qi 'mikrotik\|ROSSSH'; then
  echo "UNKNOWN — does not appear to be MikroTik RouterOS (banner: $BANNER)"
  exit 2
fi

# Step 2: try to extract version from banner or use API
# RouterOS doesn't always put version in SSH banner, so we check known fixed versions
# We'll attempt a version probe via the Winbox discovery if available
# Fallback: use SNMP or direct version check

# Try to get version via SNMP (if enabled, community=public)
VERSION=$(timeout 5 snmpget -v2c -c public "$HOST" 1.3.6.1.4.1.14988.1.1.4.4.0 2>/dev/null | grep -oP '"[^"]+"' | tr -d '"' || true)

if [[ -z "$VERSION" ]]; then
  # Try MikroTik MNDP discovery (UDP 5678) — not always available
  echo "INFO — Could not extract version via SNMP. Checking banner only."
  echo "UNKNOWN — RouterOS detected but version could not be determined remotely."
  echo "Manually verify: /system resource print (look for version >= 6.49.21 or >= 7.23.4 or >= 7.24.2)"
  exit 2
fi

echo "Detected RouterOS version: $VERSION"

# Parse major.minor.patch
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

# Version comparison
if [[ "$MAJOR" -eq 6 ]]; then
  # Fixed in 6.49.21
  if [[ "$MINOR" -lt 49 ]] || { [[ "$MINOR" -eq 49 ]] && [[ "${PATCH:-0}" -lt 21 ]]; }; then
    echo "VULNERABLE — RouterOS $VERSION is affected (fixed in 6.49.21)"
    exit 1
  else
    echo "PATCHED — RouterOS $VERSION is at or above 6.49.21"
    exit 0
  fi
elif [[ "$MAJOR" -eq 7 ]]; then
  # Fixed in 7.23.4 (long-term) and 7.24.2 (stable)
  if [[ "$MINOR" -lt 23 ]]; then
    echo "VULNERABLE — RouterOS $VERSION is affected (fixed in 7.23.4)"
    exit 1
  elif [[ "$MINOR" -eq 23 ]] && [[ "${PATCH:-0}" -lt 4 ]]; then
    echo "VULNERABLE — RouterOS $VERSION is affected (fixed in 7.23.4)"
    exit 1
  elif [[ "$MINOR" -eq 24 ]] && [[ "${PATCH:-0}" -lt 2 ]]; then
    echo "VULNERABLE — RouterOS $VERSION is affected (fixed in 7.24.2)"
    exit 1
  else
    echo "PATCHED — RouterOS $VERSION is at or above fixed version"
    exit 0
  fi
else
  echo "UNKNOWN — unexpected major version $MAJOR"
  exit 2
fi

Sources

1. MikroTik September 2026 Security Advisory
2. Nick Pratley — Reversing MikroTik's Silent Patch
3. OffSeq Threat Radar — CVE-2026-67276
4. THREATINT — CVE-2026-67276
5. TheHackerWire — CVE-2026-67276
6. MikroTik RouterOS Critical Vulnerabilities Overview
7. CISA ICS Advisory — MikroTik RouterOS