exploits4 min read

Your MikroTik Router Is a Brute-Force Target, and There's No Patch — Yet

CVE-2026-16347 (CVSS 8.8) hits every version of RouterOS: the API auth path has no real rate-limiting, lockout, or source restriction, so admin credentials can be hammered at high volume. CISA published ICSA-26-209-05 with a mitigation checklist that is the whole post.

High severity, 3 of 4. Patch at your next window. Real impact, real exposure.CVE-2026-16347
The short version

CISA's ICSA-26-209-05 (July 28) covers CVE-2026-16347 in MikroTik RouterOS and Cloud Hosted Router — CVSS 8.8, CWE-307, all versions affected (`vers:all/*`), no fix yet. The API auth path lacks meaningful rate-limiting or lockout, so an adjacent-network attacker can brute-force admin credentials at high volume until one lands. Mitigations exist and are concrete — here's the checklist.

The short version//

CISA published ICSA-26-209-05 on July 28 covering CVE-2026-16347 in MikroTik RouterOS — and the affected-version line is the part that stings: vers:all/*, for both RouterOS and Cloud Hosted Router. Not a version band. The whole line.

The flaw (CWE-307, Improper Restriction of Excessive Authentication Attempts, CVSS 8.8) lives in how RouterOS handles API authentication: there's no meaningful rate-limiting, account lockout, or source-based restriction on login attempts. Some versions do impose a fixed per-connection delay — but it can be bypassed by opening concurrent sessions, so an attacker can still hammer the admin credentials at high volume until one lands. No fix from MikroTik yet as of this writing.

The "not exploitable remotely" line that doesn't mean what you think//

CISA's advisory carries a standard sentence: "This vulnerability is not exploitable remotely." That comes straight out of the CVSS vector — AV:A, adjacent network, not AV:N (network). In plain English: the attacker doesn't need to be on your LAN or in your rack; they just need to be on the same link you're plugging into.

Why that still bites a home router: your WAN side is "adjacent" to whoever owns the ISP segment between the pole and your house, and an API port exposed to a guest network, a misrouted VLAN, or a neighbor's Wi-Fi bridge is adjacent in the most literal sense. This is exactly the self-hosted shape — a management plane that's reachable by more people than you think it is. Don't overstate it (it's not "anyone on the internet can get you"), don't understate it either (adjacent is where most home routers actually live).

Who's exploiting it (so far: nobody confirmed)//

  • No known public exploitation specifically targeting this CVE has been reported to CISA at publication time — but that was July 28, so re-check before you patch.
  • Reported by Andre Santos of União Geek, a Brazilian security outfit that reads like the name of a pirate crew and is exactly as sharp as it sounds.
  • MikroTik's HQ is in Latvia; deployment is worldwide — this is an ICS advisory because RouterOS runs in industrial environments, not just homelabs.

The mitigation checklist (this is the payload)//

With no fix available, CISA carries MikroTik's recommended mitigations verbatim. In priority order for a home or lab edge:

  1. Put a VPN or other protection layer in front of it if the API is exposed to public networks. This is the big one — an internet-facing RouterOS API with this bug is a password-guessing contest you're losing by design.
  2. Set the unsuccessful-attempt delay in /ip service to 0.1–0.5 seconds for all services, including the API (once that option is available on your version). It's not a hard lockout — it's a tax on every wrong guess, which turns "high volume" into "expensive."
  3. Do initial configuration from a trusted LAN port only, then tighten per your security requirements. Don't adopt the router over Wi-Fi and call it done.
  4. Restrict/limit access to management services from untrusted networks — the guest VLAN is not a place where winbox belongs.
  5. Apply firewall rules on the management plane wherever possible. If the API port doesn't need to be reachable, make it unreachable.
  6. Use long, randomly generated passwords rather than weak or default-simple ones — with no rate-limiting, password strength is your defense-in-depth. And here's the good news hiding in the advisory: MikroTik devices ship with a random default admin password, and since minimum complexity isn't enforced by default, keeping that generated password (or replacing it with an equally strong one) is actually fine. The people in trouble are the ones who changed "Xk3m9pQz" to "admin."

What you should do tonight//

  1. Find out if your RouterOS management plane is reachable from anywhere but your LAN — WAN, guest Wi-Fi, a bridge to another network. If yes, that's tonight's fix (VPN or firewall rule).
  2. Check /ip service for the unsuccessful-attempt delay setting and set 0.1–0.5s where available.
  3. Audit your admin password. Long and random wins here; "correct horse battery staple" loses, because there's no lockout to punish the guesser.
  4. Watch for a MikroTik fix. This story is time-sensitive — if RouterOS ships a patch that addresses CVE-2026-16347 while you're reading this, update and re-run the version check. The advisory is about 5 weeks old and still unpatched at press time.

Filed under

Sources

2 cited · 2 primary
  1. cisa.gov/news-events/ics-advisories/icsa-26-209-05Primary
  2. github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-209-05.jsonPrimary