MikroTik RouterOS CVE-2025-42611

The vulnerability requires (1) network access to at least one RouterOS security service that performs certificate validation (OpenVPN, CAPsMAN, or 802.1X), (2) knowledge or observation of a certificate authority already trusted by the target RouterOS system (or ability to introduce a new CA into the system trust store through prior compromise or misconfiguration), and (3) the ability to obtain a certificate issued by that CA or forge one if the CA's private key is accessible. Exploitation is limited by the attacker's inability to forge certificates without access to the CA private key unless the CA is weak or the attacker has already compromised it. Additionally, if RouterOS enforces certificate pinning or additional validation rules beyond the shared trust store for specific services, this may further constrain exploitation. The vulnerability affects default configurations in multi-service environments where multiple CAs are trusted (typical in enterprise deployments), but is mitigated in minimal deployments using only one service with a single CA.

This vulnerability presents moderate-to-significant real-world risk despite a CVSS score of 6.5. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U) confirms remote, unauthenticated, low-complexity exploitation against default configurations with no user interaction required-favorable conditions for attacker scalability. The confidentiality and integrity impact (C:L/I:L) is partial rather than complete compromise, which CVSS correctly reflects. However, the practical impact may be underestimated by the raw score because: (1) successful exploitation grants authentication bypass in multiple critical security services simultaneously, (2) RouterOS is deployed in enterprise network edge roles where such services are actively used, and (3) the vulnerability exploits a design flaw in certificate trust architecture rather than a parsing bug, suggesting sustained exploitation window. The attack requires either network access to the vulnerable services (OpenVPN, CAPsMAN, Dot1x) and knowledge of a CA trusted by the system, or ability to introduce a new CA into the trust store. EPSS score, KEV status, and POC availability are not provided in the input data, preventing assessment of current active exploitation or proof-of-concept availability. The absence of this data is notable given ENISA reporting and suggests either early-stage disclosure or targeted vulnerability.

An attacker with network access to a RouterOS instance running OpenVPN obtains or creates a certificate signed by any CA already present in the system's trust store (e.g., a CA legitimately used for a different service like CAPsMAN). The attacker then attempts to authenticate to a different service, such as Dot1x, using this certificate. Due to the shared certificate validation logic and scope confusion, RouterOS incorrectly trusts the certificate in the Dot1x context despite the CA not being intended for that service. The attacker gains authentication bypass and can proceed to access network resources or service functionality that should require proper authentication.