MikroTik RouterOS EUVD-2026-72026

The attacker must occupy a network-adjacent or upstream position enabling interception or redirection of outbound TLS connections initiated by the RouterOS device - achievable via ARP poisoning on the local segment, upstream BGP advertisement manipulation, or DNS hijacking of RouterOS's configured resolvers. No authentication to the router and no non-default configuration on the router are required; any RouterOS device that makes outbound TLS connections (a default behavior for update checks, cloud management, and similar services) is a valid target. Exploitation is limited to TLS sessions that RouterOS itself initiates, not arbitrary forwarded traffic. On the device side, the sole structural prerequisite - the presence of an e=3 root CA in the default trust store - is present in unmodified RouterOS installations; no administrator misconfiguration is required.

The CVSS 4.0 score of 6.3 with AT:P honestly reflects the positioning prerequisite - the attacker must intercept or redirect RouterOS-initiated outbound TLS traffic - but the practical risk is elevated substantially by the availability of a public exploit, a CERT-PL advisory characterizing active exploitation, and a reverse-engineering write-up of the silent patch that lowers attacker skill requirements significantly. Even a mid-sized ISP or municipal network operator in zabrze should treat this as urgent, since MikroTik devices are routinely used as border routers where outbound TLS to management APIs, auto-update services, and cloud management endpoints is default behavior, expanding the realistic attack surface. The vendor's conservative VC:L/VI:L impact rating understates real-world consequence: successful impersonation of a management or update server exposes administrative credentials and can facilitate arbitrary firmware injection. The 'Jwt Attack' tag in the input metadata is inapplicable to this X.509/RSA flaw and should be disregarded when assessing the scope of the issue.

An attacker positioned upstream of a MikroTik router - via BGP route injection, ARP poisoning, or DNS hijacking - intercepts an outbound TLS handshake initiated by RouterOS to an auto-update or cloud management endpoint. The attacker applies the cube-root PKCS#1 v1.5 forgery technique against the e=3 root CA in RouterOS's trust store to construct a forged intermediate CA, then signs a leaf certificate for the target hostname; RouterOS validates the chain and completes the handshake. A public exploit and independent reverse-engineering of the MikroTik silent patch (npratley.net) confirm this scenario is practically executable without access to any CA private key.