Yesterday this site covered a forge on a batch-patch cadence. Tonight the same argument reaches the layer below it — the router at the front door of every community network this site has written about.

CERT Polska disclosed six MikroTik RouterOS vulnerabilities on September 5 and confirmed active exploitation of a two-bug chain they named MikroTrick. Chained, the bugs take full control of a device with no credentials at all. The Shadowserver Foundation counts 122,500+ MikroTik devices with SSH reachable from the open internet — 11,300 in Brazil, 7,100 each in the US and Indonesia, 6,300 in the Czech Republic. The fixes have been in the wild since September 3. The exploitation has been running since at least September 2.

If you operate network infrastructure for a community — a mesh node, a municipal network, a fire hall's edge router — this is your layer.

The chain, in two moves

The bugs were found by Sławomir Rozbicki at CERT Polska and coordinated with MikroTik before publication. The exploit chain combines two of them:

CVE-2026-67276 — SSH authentication bypass (CVSS 9.2). RouterOS matched an incoming SSH key against a user's authorized key by comparing the key type and modulus and skipping the exponent. Signature verification used the client-supplied key. So an attacker who knows your username and your RSA public modulus supplies a key with exponent 1, forges a valid signature, and lands an SSH session as you — without ever holding your private key. Your SSH key becomes a username.

CVE-2026-86060 — privilege escalation via a crafted username (CVSS 9.2). A username beginning with a prohibited character flows through the SSH login path and flips the trusted RouterOS policy mask. The resulting session holds full administrative privileges.

Move one gets you in. Move two makes you root. No password, no key, no phishing — just SSH reachable from a public network. The observed attacks left a specific log artifact:

login failure for user -2 from <ip> via ssh user <name> added by ssh:-2@<ip>

…plus a highly privileged account named ops. CERT Polska attributes the successful attacks it analyzed to 82.192.72.4, with 103.102.31.18 used in exploitation attempts. Those are indicators of compromise, not an exhaustive attacker list — treat them as the minimum you check for.

The other four

The chain is the urgent part, but the surrounding four CVEs describe a device that was weaker than its reputation, and two of them matter to how you run a community network:

  • CVE-2026-67277 (CVSS 8.8) — the bandwidth-test service accepts a "related" btest connection before the primary session authenticates, exposes uninitialized kernel packet buffer data, and can underflow a packet-size interval into a remote kernel restart. If your community node runs bandwidth-test for link tuning — mesh operators do this — the service itself is an unauthenticated crash primitive.
  • CVE-2026-67278 — 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 who can redirect an outbound TLS connection from your router can forge a trusted intermediate — with the root's public certificate alone — and impersonate any TLS host the router calls. Firmware update channels included. If your edge device fetches its own updates, the update path was spoofable.
  • CVE-2026-67279 — a rekey-handling flaw lets an unauthenticated client skip authentication and open an exec channel: file write and overwrite in the RouterOS managed namespace, including support files that hold configuration.
  • CVE-2026-67281 — WebFig /jsproxy unauthenticated file read via a stale uninitialized principal pointer; parent-directory escape, root-owned files, credential stores.

Six bugs, and they are not random: an auth layer that skips part of a public-key comparison, a certificate validator that accepts forged signatures, a service exposed with no authentication, and a web UI reading root-owned files. The RSA exponent skip and the e=3 trust-store root are both textbook signature-verification failures that unit tests with well-formed keys never catch. Somebody had to attack the verifier itself. That is a signal about where router software security is heading.

What to do

  1. Patch now. Fixes shipped September 3 in RouterOS 7.25beta3, 7.24.2 (stable), 7.23.4 (long-term), and 6.49.21 (legacy long-term). "Check for updates" has the option, or pull the package from MikroTik's download page. MikroTik shipped its first-ever push notification through the app for this one. Treat that as the urgency signal it is.

  2. Assume compromise if SSH was exposed — the upgrade alone is not the fix. MikroTik's patched builds scan startup config for known compromise signs, disable suspicious entries, and set a "Flagged" status (/system/device-mode/print). Two hard caveats from CERT Polska: the Flagged marker catches only selected traces, and its absence is not proof of safety. Audit every device yourself: unknown users, scripts, scheduler tasks, proxy servers, tunnels, and specifically any account named ops. Assume a flagged device is taken over: reconfigure from scratch, rotate every secret it held, then rebuild.

  3. Make remote management the exception. Default MikroTik configs block SSH from the WAN; every one of those 122,500 exposed devices got that way by manual change. Take management ports off the internet entirely and reach them over WireGuard instead. If a remote-management exception is unavoidable, restrict it to known management IPs and log the exceptions. This is the same rule this site keeps applying at every layer: the forge closed registration to kill the exploit prerequisite; here you close the port.

  4. Do not initiate TLS or SSH from an unpatched device. CVE-2026-67278 makes the device's own outbound connections a liability: the built-in SSH clients (/system ssh, /system ssh-exec) and any TLS the router originates can be impersonated or abused until it is patched. Update first, then manage.

  5. Inventory the exposure honestly. If you cannot answer "is SSH reachable from outside?" for every MikroTik device in your deployment tonight, that unknown is the finding. ip service print on each device; check the input firewall chain; scan your own public address from outside your network. One evening of checking beats one morning of finding out.

Why the community-network layer is the point

Community networks are the demographic this bug was made for, and not because of anything about the operators:

  • MikroTik is the default hardware of community meshes and low-budget municipal networks. It is cheap, capable, and everywhere. NYC Mesh runs it. Countless rural co-ops and city hall edge networks do too.
  • The exposure shape fits. A mesh supernode or a municipal POP needs remote management — often over SSH — and volunteer-run operations drift toward leaving management ports reachable "temporarily." Temporary becomes the permanent configuration that Shadowserver's scanner counts.
  • The blast radius is the whole network. A router is not one more service. It sits at the edge: it can rewrite DNS, tunnel traffic, alter firewall rules, and become the staging point for everything behind it. For a community network, a router compromise means the attacker owns the neighborhood's network path — and the ISP-style services that terminate on it.

There is also a discipline angle. The Proxmox EOL post argued that end-of-life is a countdown you are inside of; the Gitea post extended the argument to forges on batch cadences. Add the edge layer: your routers and firewalls are patch surfaces on the same schedule as everything else you run. RouterOS devices frequently sit at firmware levels years old because "it works and nobody touches it." MikroTrick is the argument against that posture — an attack running since September 2, patched since September 3, against hardware with 122,500 SSH doors open.

And a note on disclosure: CERT Polska published on an accelerated schedule because patched packages were already public and comparative analysis was reconstructing the bugs. MikroTik withheld details for a patch window. The result is that operators had fixes three days before full technical detail — the coordination worked. The lesson is not that vendors should say more or less; it is that the patch is the event, and every operator's calendar should be driven by fix availability, not by writeups.

OpenWrt operators get no pass either: 24.10's security support ended September 5, 2026, days ago. The current supported series is 25.12. If your community's edge runs either, tonight is a patch-and-inventory night.

The habit, continued

Three nights running, this site's advice has been the same shape at three layers: identity, forge, edge. Self-hosting puts you in control; it also puts you on the hook. The router that carries your community's traffic deserves the same patch discipline as the Keycloak and the Gitea behind it — plus one habit none of the others need: assume the edge is the layer an attacker wants most, and audit it first, not last.

Sources: CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited, CERT Polska — CVE details, MikroTik security bulletin, Shadowserver via Cybernews, Malwarebytes