CVE-2026-67278 in MikroTik
Summary
by MITRE • 09/05/2026
MikroTik RouterOS accepts malformed RSA/PKCS#1 v1.5 signatures during X.509 validation. Because its trust store includes an e=3 root CA, an attacker controlling or redirecting an outbound RouterOS TLS connection can use the root’s public certificate - without its private key - to forge a trusted intermediate and issue certificates for arbitrary hostnames, enabling TLS server impersonation.
This issue was fixed in versions: 6.49.21 (Lont-term), 7.23.4 (Lont-term) and 7.24.2 (Stable)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/06/2026
The vulnerability described constitutes a critical failure in the cryptographic validation logic within MikroTik RouterOS, specifically affecting the implementation of X.509 certificate chain verification during Transport Layer Security connections. The core technical flaw lies in the acceptance of malformed RSA signatures that adhere to PKCS#1 v1.5 padding standards but lack proper integrity checks or are crafted using specific mathematical properties associated with small public exponents. In standard cryptographic practice, RSA signatures must be verified against a private key held by the certificate issuer. However, this implementation flaw allows an attacker to bypass the need for the private key entirely when dealing with certificates signed by root Certificate Authorities that utilize a public exponent of three. This specific mathematical weakness enables what is known as a Bleichenbacher-style attack or related small-exponent RSA forgery, where the structure of the signature can be manipulated to pass validation checks without possessing the corresponding secret material.
The operational impact of this vulnerability is severe because it directly undermines the fundamental trust model of public key infrastructure. By exploiting the inclusion of an e=3 root CA in the RouterOS default trust store, a network attacker who controls or redirects outbound TLS traffic can forge intermediate certificates that appear valid to the router. This allows for complete TLS server impersonation, where the attacker presents a forged certificate for any arbitrary hostname. Consequently, sensitive data transmitted from the MikroTik device, such as management credentials, configuration details, and operational logs, can be intercepted in plaintext by the malicious actor. Furthermore, this capability enables man-in-the-middle attacks that compromise the integrity of remote management sessions, potentially allowing unauthorized control over network infrastructure devices running affected versions of RouterOS.
From a threat intelligence perspective, this vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-347 Improper Verification of Cryptographic Signature. The exploitation technique maps to MITRE ATT&CK techniques related to Man-in-the-Middle attacks and Credential Access via Network Sniffing or Protocol Manipulation. The specific use of a small public exponent like e=3 is a known risk factor in RSA implementations, often discouraged by modern security standards such as NIST SP 800-57 due to its susceptibility to certain mathematical attacks if not implemented with rigorous padding schemes and validation checks. The failure here indicates that the RouterOS SSL/TLS library did not adequately enforce strict signature verification rules or failed to reject signatures that do not meet expected structural integrity requirements for PKCS#1 v1.5 when processed against specific root keys.
Mitigation strategies must prioritize immediate software updates as the primary defense vector. Administrators should upgrade MikroTik RouterOS to version 6.49.21, 7.23.4, or 7.24.2 and later, where this validation logic has been corrected to reject malformed signatures and enforce stricter compliance with cryptographic standards. In environments where immediate patching is not feasible due to operational constraints, network segmentation should be employed to restrict outbound TLS connections from affected devices to only trusted endpoints. Additionally, implementing certificate pinning for critical management interfaces can provide an additional layer of security by ensuring that the device accepts certificates only from explicitly defined issuers, thereby mitigating the risk posed by forged intermediate certificates even if the underlying validation logic remains vulnerable in older versions. Regular auditing of trust stores and removal of unnecessary root CAs with known weaknesses like small public exponents is also recommended to reduce the attack surface for future cryptographic exploits.