MikroTik RouterOS CVE-2026-67278 lets forged TLS and SSH signatures pass verification

What the flaw is

On 5 September 2026, CERT Polska disclosed CVE-2026-67278, a vulnerability in MikroTik RouterOS 7.x concerning how RSA signatures are verified under the PKCS#1 v1.5 scheme. According to the advisory, summarised in a dev.to write-up, devices running affected builds accept malformed signatures in two separate code paths: validation of TLS/X.509 certificate chains and authentication of RSA SSH host keys. Complete fixes are available in RouterOS 7.23.6 on the long-term branch and 7.24.3 on the stable branch. CERT Polska also published a separate technical account of its disclosure process.

How the attack works

The dev.to analysis lays out the mechanics. RouterOS carries a root certificate in its trust store whose RSA public exponent is 3. Combined with the faulty verification, an attacker who can control or redirect an outbound TLS connection from the device can assemble a trusted intermediate certificate without holding any private key, then issue certificates for arbitrary hostnames. From the router's point of view, the resulting chain looks legitimate even though it was forged.

The same defective check weakens RSA-based SSH host-key authentication, so a traffic-redirection position also enables host impersonation during SSH connections. Exploitation has two preconditions: the attacker needs the ability to redirect traffic, and the target has to be running an affected build.

Why it stays hidden

The failure mode is quiet. Nothing crashes and nothing visibly breaks; the symptom is trust landing in the wrong place. Outbound connections start reaching endpoints nobody configured, certificate chains validate when they should be rejected, and management automation may begin talking to hosts it was never pointed at. Left in that state, a device can leak configuration or credential material outward without anyone noticing.

Affected versions

Per CERT Polska, vulnerable builds cover RouterOS 7.0.0 through versions before 7.23.6, and 7.24 through versions before 7.24.3. Two interim releases, 7.23.4 and 7.24.2, shipped incomplete fixes and should be treated as unpatched.

Sizing the exposed fleet

ZoomEye figures cited in the write-up, collected on 23 September 2026, show 9,559 assets matching RouterOS SSH fingerprints, while a query tagged with the CVE identifier returned zero results. Both numbers need context. The 9,559 count reflects SSH-reachable RouterOS devices rather than confirmed-vulnerable ones, and the zero reflects gaps in CVE tagging rather than proof that no exposed device is affected.

What operators should do

• Upgrade to 7.23.6 or 7.24.3 and confirm the running version after the change.
• Record each device's normal outbound destinations and raise an alert when new or changed endpoints appear.
• Keep and review certificate-validation failure logs instead of discarding them.
• Restrict management access to trusted networks, so a redirect attempt cannot also turn into credential exposure.
• Mark 7.23.4 and 7.24.2 as unpatched in inventory and monitoring tooling.

Why it matters

Routers are where TLS and SSH trust decisions carry the most weight: they originate firmware updates, API traffic and management sessions for entire networks. A bug that lets forged signatures through means an attacker able to redirect traffic can impersonate any endpoint the device trusts, with no key compromise required. The incomplete interim patches add a trap for operators who upgraded once and assumed the problem was closed. Because the telltale sign is quietly redirected trust rather than a visible failure, detection depends on destination baselining and log review, disciplines many networks have yet to build. For anyone running RouterOS, verifying the exact version string is the single highest-value action available today.