Summary
- All versions of MikroTik RouterOS and Cloud Hosted Router are affected by CVE-2026-16347, a flaw that permits unlimited authentication attempts against the API service.
- The built-in per-connection delay can be bypassed by running concurrent sessions, rendering it an ineffective control.
- CVSS v3.1 score is 8.8 (High); attack vector is adjacent network, meaning remote internet exploitation is not possible but local or VPN-accessible networks are at risk.
- No patch exists. MikroTik’s guidance focuses on firewall restrictions, strong passwords, and VPN-gating of the API.
- CISA reports no known public exploitation of this vulnerability at this time.
What the vulnerability is
CISA published an advisory on 28 July 2026 covering CVE-2026-16347, a weakness in how MikroTik RouterOS handles API authentication. The flaw is classified under CWE-307 — Improper Restriction of Excessive Authentication Attempts. In practical terms, the router’s API does not enforce meaningful rate-limiting, account lockout, or source-based restrictions, so an attacker positioned on the same network segment can submit a high volume of login attempts without the device pushing back.
Why the built-in delay does not help
Some versions of RouterOS do insert a fixed delay after a failed login attempt. However, the advisory notes this control can be bypassed by opening multiple concurrent sessions. An attacker simply spreads attempts across several simultaneous connections, effectively maintaining a high throughput of guesses while the per-connection timer is technically observed. The net result is that the delay provides little meaningful protection against a determined adversary.
Scope and affected products
The advisory lists all versions of both MikroTik RouterOS and MikroTik Cloud Hosted Router as affected. There is no version exclusion. MikroTik equipment is deployed worldwide across commercial facilities and information technology sectors, according to CISA. The company is headquartered in Latvia. The vulnerability was reported to CISA by Andre Santos of União Geek.
Attack vector and severity
The CVSS v3.1 score is 8.8, rated High, with the vector string indicating an adjacent-network attack — meaning an attacker needs to be on the same network segment or subnet, not the open internet. CISA confirms the vulnerability is not exploitable remotely in the traditional sense. That said, ‘adjacent’ in practice can include cloud-hosted environments, poorly segmented enterprise networks, or any scenario where the MikroTik API service is reachable from a shared or semi-trusted network. The confidentiality, integrity, and availability impact ratings are all assessed as High.
No patch available
MikroTik has not released a fix. CISA’s advisory reflects MikroTik’s own guidance, which at this point is entirely mitigation-based. Organisations running these devices need to treat the vulnerability as a standing exposure and apply compensating controls until a patch is issued. MikroTik has directed users to contact its support team for further assistance.
Why it matters
MikroTik hardware is common in enterprise branch offices, carrier-grade deployments, and cloud infrastructure. A successful brute-force attack against the API service could hand an attacker full administrative control — the CVSS scoring reflects High impact across confidentiality, integrity, and availability. While the adjacent-network vector limits opportunistic internet-scale attacks, it does not reduce risk for organisations with flat or poorly segmented networks, cloud-hosted instances accessible from shared environments, or sites where the management interface is inadvertently reachable from a broader subnet. The absence of a patch means CISOs cannot simply schedule an update cycle and move on; active compensating controls need to be in place and verified now, and the exposure must be tracked until MikroTik ships a fix.
What to do now
- Audit your environment to identify all MikroTik RouterOS and Cloud Hosted Router instances, noting which have the API service enabled and whether that service is reachable from anything other than a trusted LAN segment.
- Place the API and all management services behind a strong VPN or equivalent access control layer if any exposure beyond a trusted local network exists.
- Apply firewall rules to restrict access to management services, permitting only known, trusted source addresses.
- Ensure all MikroTik devices use long, randomly generated passwords rather than weak or default credentials — the advisory specifically notes that minimum password complexity is not enforced by default.
- Retain or restore the device’s default randomly generated password if it has been replaced with something weaker.
- Configure the unsuccessful-attempt time range setting (0.1 to 0.5 seconds) in /ip service for all services including the API, as recommended by MikroTik, once that option is available on your version.
- Perform initial configuration only from a trusted LAN port, then lock down access before exposing services further.
- Monitor for any anomalous authentication activity against MikroTik API services and establish alerting thresholds for repeated failures.
- Contact MikroTik support and track the vendor’s patch release schedule so updates can be applied promptly when available.
