CVE-2026-67278

Executive Summary

CVE-2026-67278 is a cryptographic signature-validation flaw in MikroTik RouterOS 7.x in which malformed RSA/PKCS#1 v1.5 signatures are accepted during X.509 certificate chain validation. Because the RouterOS trust store includes a root CA with a public exponent of e=3, an attacker who controls or redirects an outbound TLS connection from the device can forge a trusted intermediate certificate using only the root's public certificate—no private key required—and then issue certificates for arbitrary hostnames. The result is TLS server impersonation, allowing man-in-the-middle interception and manipulation of RouterOS-initiated outbound TLS sessions. The vulnerability carries a CVSS v3.1 base score of 9.1 (Critical), is remotely exploitable without authentication, and has a public PoC while not yet being listed in CISA KEV.

Technical Analysis

The vulnerability resides in RouterOS's X.509 certificate path validation logic, specifically in how it verifies RSA signatures that use the PKCS#1 v1.5 padding scheme. Proper PKCS#1 v1.5 signature verification requires a strict, byte-exact comparison of the recovered DigestInfo structure against the expected ASN.1 DER encoding of the digest algorithm identifier and hash value. When that check is relaxed—for example, by tolerating malformed padding, ignoring trailing bytes, or permitting non-canonical encodings, all of which map to CWE-347 (Improper Verification of Cryptographic Signature)—the validator can be induced to accept a signature that was never legitimately produced by the signer.

The impact is amplified by a second, compounded weakness: the RouterOS trust store includes a root CA certificate whose RSA public exponent is e=3. Under a small-exponent configuration, when the signature-verification step is insufficiently strict, the low-exponent (e=3) arithmetic combined with permissive PKCS#1 v1.5 parsing makes signature forgery practical. Critically, a root CA's public certificate is by definition public, so an adversary requires no private key material to construct a forged intermediate. In a properly implemented validator, forging a subordinate certificate would still fail because the signature over the intermediate must verify against the root's public key using strict padding checks. Here, the malformed-signature acceptance defeats that guarantee.

The attack surface is any RouterOS-initiated outbound TLS connection where a certificate chain is validated against the built-in trust store—for example, remote management, update, cloud, or other administrative/outbound TLS connections originated by the router. The device is the TLS client in these flows; the attacker positions themselves on the path (via network control or redirection) and replies with a forged chain.

The flaw is confined to the 7.x branch. It was fixed in RouterOS 7.23.4 on the Long-term channel and 7.24.2 on the Stable channel. Note that patch confidence here is assessed as 0/4: no patch evidence was confirmed from the tracked sources in this dataset, even though the upstream description names the fixed versions. Affected-version data in this dataset is empty and should be corroborated against the vendor's official advisory.

It is worth stating precisely what is and is not claimed. The NVD description does not disclose specific function names, API paths, or code artifacts. The forgery described is class-level: strict PKCS#1 v1.5 validation is not enforced, and an e=3 root CA in the trust store makes malformed-signature acceptance exploitable. No private key of the root or any legitimate CA is required.

Exploitation Scenarios

The chain below is derived strictly from the NVD description and applies at the vulnerability-class level. No public exploit code is confirmed in this dataset beyond a "Public" PoC status; no specific payload artifacts are asserted.

1. Reconnaissance / target identification. The adversary identifies a MikroTik RouterOS 7.x device that initiates outbound TLS connections and validates server certificates against its built-in trust store. Network positioning (on-path or control of DNS/routing) is the key prerequisite, because the attacker must be able to control or redirect the outbound TLS connection the device makes. The device acts as the TLS client; the attacker will act as, or intercept, the TLS server side.

2. Triggering the flaw class. When the RouterOS device opens an outbound TLS connection, it receives a server certificate chain. Legitimate validation would verify each signature up to a trusted root using strict RSA/PKCS#1 v1.5 verification. Because malformed PKCS#1 v1.5 signatures are accepted, the attacker supplies a forged chain that passes validation despite not being legitimately signed. Because the trust store contains an e=3 root CA, the attacker uses that root CA's public certificate—which is public information—as the anchor from which to forge a trusted intermediate.

3. Payload / execution method (vulnerability-class level). The attacker forges an intermediate CA certificate whose signature validates against the e=3 root under the permissive parser, then issues a leaf certificate for the arbitrary hostname the RouterOS device is attempting to reach. The malformed RSA/PKCS#1 v1.5 signature is what bypasses the intended strict check. The attacker does not need the root's private key, nor any legitimate CA private key. No specific function names or code patterns are asserted here because the description does not provide them.

4. Post-exploitation impact. With a forged, "trusted" certificate accepted by the device, the attacker achieves TLS server impersonation for the arbitrary hostname. This enables active man-in-the-middle: interception, decryption, and modification of the TLS-protected session between the RouterOS device and the intended endpoint. Depending on what that outbound channel carries, the adversary can read or tamper with sensitive administrative or update traffic, escalate to broader compromise, and maintain a position that undermines the confidentiality and integrity of RouterOS-originated TLS communications—consistent with the CVSS impact of High confidentiality and High integrity with no availability impact.

Impact Assessment

The CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N yields a base score of 9.1 (Critical). Each subscore maps directly to the attack:

• AV:N (Network): exploitable over the network; the attacker need not be on the local segment—only able to control or redirect a RouterOS outbound TLS connection.
• AC:L (Low): no special conditions beyond network positioning; the forgery uses public certificate material.
• PR:N (None): no authentication or privileges required.
• UI:N (None): no user interaction is needed; the device's automated TLS validation does the work.
• S:U (Unchanged): impact is scoped to the vulnerable component and its communications.
• C:H / I:H: the attacker can read and modify TLS-protected data by impersonating the server, directly compromising confidentiality and integrity.
• A:N: no direct availability impact is described.

Business impact centers on loss of trust in outbound TLS from RouterOS devices: management, update, cloud, or other administrative channels initiated by the router can be intercepted and altered. Blast radius is any organization with unpatched RouterOS 7.x devices that originate validated TLS connections across an attacker-reachable path. Because the forgery uses a public root certificate, exploitation does not require theft of secret key material, lowering the barrier and complicating attribution. Note EPSS is low (0.00278; ~18th percentile) and CISA KEV status is NO—suggesting limited observed exploitation to date—but the public PoC status and Critical severity warrant prioritized remediation. The lack of CISA KEV listing or confirmed in-the-wild campaigns should not be read as low risk.

Detection Guidance

Detection for this issue is difficult at the network signature level because the malicious artifact is a malformed-but-accepted X.509 chain carrying RSA/PKCS#1 v1.5 signatures—validation happens inside the device, not in traffic the sensor can verify cleanly. The rules below therefore focus on chain anomalies (small e=3 root anchors, unexpected intermediate issuance, certificate subject/issuer mismatches) and on log/telemetry indicators of RouterOS TLS validation and trust-store activity. Where a field cannot be reliably derived from the description, the rules use behavioral proxies and should be tuned in a lab before production deployment.

Sigma Rule

title: MikroTik RouterOS X.509 Chain Validation Anomaly (CVE-2026-67278)
id: 3f9c2b7e-1a4d-4c8b-9e21-7b6f0c5d2a11
status: experimental
description: Detects RouterOS log or proxy telemetry indicating suspicious X.509 chain
  validation activity consistent with forged intermediate acceptance via malformed
  RSA/PKCS#1 v1.5 signatures and an e=3 root CA trust anchor.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-67278
author: valtersit.com
date: 2026-01-01
logsource:
  product: mikrotik
  service: routeros
detection:
  selection_chain:
    message|contains:
      - 'certificate'
      - 'x509'
      - 'chain'
      - 'verify'
  selection_forge:
    message|contains:
      - 'PKCS#1'
      - 'signature'
      - 'intermediate'
      - 'trust'
  condition: selection_chain and selection_forge
falsepositives:
  - Legitimate certificate rotation and CA update operations
  - Administrative certificate import/export
level: high
tags:
  - attack.t1190
  - cve.2026-67278

YARA Rule

rule CVE_2026_67278_RouterOS_X509_PKCS1_Forgery
{
    meta:
        description = "Detects certificate material associated with forged X.509 intermediates exploiting malformed RSA/PKCS#1 v1.5 validation in MikroTik RouterOS (CVE-2026-67278)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-67278"
        date = "2026-01-01"
        severity = "critical"
    strings:
        $pem_begin = "-----BEGIN CERTIFICATE-----"
        $pem_end   = "-----END CERTIFICATE-----"
        $rsa_oid   = { 2a 86 48 86 f7 0d 01 01 01 }
        $sha256rsa = { 2a 86 48 86 f7 0d 01 01 0b }
        $pkcs1_oid = { 2a 86 48 86 f7 0d 01 01 }
    condition:
        ($pem_begin and $pem_end and $rsa_oid) or
        (uint16(0) == 0x3082 and $sha256rsa and $pkcs1_oid)
}

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2026-67278 MikroTik RouterOS forged X.509 chain / PKCS#1 v1.5 anomaly"; flow:established,to_client; tls.subject:"CN="; tls.issuerdn; sid:202667278; rev:1; metadata:created_at 2026_01_01, cve CVE_2026-67278, affected_product MikroTik_RouterOS; classtype:attempted-recon; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-67278;)

Elastic Detection

sequence by process.entity_id with maxspan=30s
  [network where network.protocol == "tls" and
    tls.client.server_name != null and
    process.name in ("routeros", "routeros-agent")]
  [network where network.protocol == "tls" and
    tls.server.x509.issuer.common_name != null and
    tls.server.x509.subject.common_name != null and
    tls.server.x509.issuer.common_name != tls.server.x509.subject.common_name]

Splunk SPL Query

index=mikrotik sourcetype=routeros
(("X.509" OR "certificate" OR "chain" OR "verify") AND
 ("PKCS#1" OR "signature" OR "intermediate" OR "trust"))
| stats count min(_time) as first_seen max(_time) as last_seen
  values(message) as evidence by host, src, dest
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="mikrotik,routeros,cve-2026-67278,">
  <rule id="2026727" level="12">
    <decoded_as>json</decoded_as>
    <field name="message">\.*(X\.509|certificate|chain|verify)\.*</field>
    <field name="message">\.*(PKCS#1|signature|intermediate|trust)\.*</field>
    <description>CVE-2026-67278: MikroTik RouterOS suspicious X.509 chain validation / PKCS#1 v1.5 signature activity</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Although the upstream description identifies RouterOS 7.23.4 (Long-term) and 7.24.2 (Stable) as the fixing versions, this dataset did not independently confirm a patch from any tracked source, and affected-version data is empty. Treat the device fleet as unpatched until you verify firmware versions directly against the vendor's official advisory.

1. Immediate mitigations

• Patch/upgrade first if you can confirm availability (see step 2); if you cannot, isolate exposure now.
• Harden outbound path trust: restrict RouterOS outbound TLS to well-defined, trusted destinations where possible, and use network-layer controls so a device cannot be silently redirected to an attacker-supplied TLS endpoint.
• Reduce reliance on RouterOS-originated TLS for sensitive management/administrative flows; prefer out-of-band or independently validated management channels.
• Avoid untrusted/transient networks for RouterOS WAN or management paths; use tight ACLs and firewall rules to constrain where the router may open TLS connections.
• Test, in a lab, whether your RouterOS fleet trusts any root CA with e=3. Because the description ties exploitability to an e=3 root in the trust store, removing or not relying on such an anchor where operationally feasible reduces exposure—but validate that this does not break required trust chains before applying fleet-wide.

2. Patch / upgrade steps

• Upgrade to RouterOS 7.23.4 (Long-term) or 7.24.2 (Stable) or later, per the versions stated in the upstream description.
• Verify actual running firmware on each device; do not assume version from inventory alone.
• Confirm the vendor advisory text before scheduling; this dataset's patch confidence is low, so validate the fix directly.
• Reboot/apply as required and re-test certificate validation behavior post-upgrade.

3. Long-term hardening

• Inventory all RouterOS 7.x devices and maintain a firmware baseline; enroll devices in a disciplined patch cadence on the Long-term channel where stability matters.
• Audit trust stores periodically and remove unnecessary or low-assurance root CAs, particularly those using small RSA exponents such as e=3.
• Monitor outbound TLS destinations for anomalies; alert on unexpected certificate issuers/intermediates from RouterOS-originated sessions.
• Track the CVE through NVD and MikroTik advisories; reassess EPSS/KEV status and re-prioritize as exploitation evidence evolves.

References

• NVD — CVE-2026-67278: https://nvd.nist.gov/vuln/detail/CVE-2026-67278
• MikroTik RouterOS Security Advisories (vendor): https://mikrotik.com/support
• CWE-347 — Improper Verification of Cryptographic Signature: https://cwe.mitre.org/data/definitions/347.html
• CVSS v3.1 Specification (FIRST): https://www.first.org/cvss/v3.1/specification-document
• CISA Known Exploited Vulnerabilities Catalog (status check — not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No confirmed threat-actor campaign or exploit-in-the-wild evidence is provided in this dataset; CISA KEV status is NO. A public PoC is indicated, but no exploit code is confirmed here. Reassess if KEV listing or vendor confirmation of active exploitation emerges.