CERT Polska says MikroTik routers were taken over without passwords: how organisations should respond

Poland’s national incident-response team has documented MikroTrick, an exploit chain that allowed an attacker to obtain full control of a MikroTik router without a password, SSH key or completed authentication. Attacks targeted RouterOS devices exposing SSH to public networks, and the vulnerabilities were exploited before full technical details were disclosed.

For an organisation, a router is not merely a box that provides internet access. It may terminate VPNs, enforce segmentation, provide administrative access, connect branches and route traffic to critical services. Its compromise can enable interception, traffic redirection, persistence and attacks against internal systems.

What CERT Polska discovered

The team identified six RouterOS vulnerabilities and coordinated their disclosure with MikroTik. The chain named MikroTrick combined CVE-2026-67279 with CVE-2026-86060. The first flaw let an SSH connection move from the authentication phase into session handling without confirming the user’s identity. The second allowed a crafted username to pass an attacker-controlled privilege mask to the login process.

Together, the bugs delivered full administrative access. Public logs showed an unusual sequence: a failed login for the user -2 followed shortly afterwards by creation of an account. CERT Polska confirmed exploitation of the chain against devices with publicly reachable SSH.

Fixes were released in RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21. MikroTik sent a security push notification to users of its mobile app, and CERT Polska advised urgent installation. Patched releases also include a “Flagged” mechanism that detects selected signs of unauthorised changes.

An absent flag does not prove that the device is clean. The mechanism recognises only some known artefacts. A patch closes the vulnerability, but it does not automatically remove every account, tunnel, script or secret that an attacker may have added beforehand.

The first decision: find every affected router

An organisation should start with inventory, not a statement that “head office has been updated”. MikroTik devices may sit in a branch, warehouse, retail site, employee’s home, supplier-managed cabinet, camera network or backup circuit. A device forgotten for two years is just as much a gateway as a new router in the main office.

For each device, establish the model, RouterOS version, owner, location, public services, management path, trusted configuration backup and business dependencies. If SSH, HTTP/HTTPS management or the bandwidth-test service is internet-accessible, priority increases. Moving a service to a non-standard port is not a security control.

Where an immediate update is impossible, CERT Polska advises temporarily disabling exposed services or limiting them to trusted management networks. That reduces exposure but does not replace a fixed RouterOS release.

Patching is the beginning, not the end

After updating, inspect the “Flagged” state, logs and configuration. Unknown users, scripts, scheduled jobs, proxies and tunnels require particular attention. The ops account and entries involving user -2 are indicators described by CERT Polska, but their absence does not rule out other modifications.

Compare the current configuration with the last known trusted version. Someone familiar with the environment must assess the difference because not every change is malicious and a legitimate administrator may have worked at the same time. Review dependent systems too: VPN servers, identity services, devices reachable through tunnels and locations where passwords or keys used by the router were stored.

If evidence suggests compromise, do not begin with a reset. Isolate the device, preserve logs and configuration, and report the incident to the appropriate CSIRT. After preserving evidence, factory-reset the router, rebuild it from a trusted source and rotate related passwords, keys and other secrets. CERT Polska explicitly warns against blindly restoring a complete backup from a potentially compromised device.

What a small-business owner should ask

If an operator or IT provider manages the router, ask specific questions: which RouterOS version is installed, whether SSH was publicly reachable, when the update was applied, which indicators were checked and whether the configuration was compared with a trusted baseline. “It is working” says nothing about compromise.

Do not run arbitrary commands copied from comments when you do not understand their effect on connectivity and configuration. Loss of router access can stop payments, telephony, monitoring or remote work. The update needs a configuration backup, service window, accountable owner and rollback plan, but active exploitation means it cannot be deferred without a deadline.

Once response is complete, remove public administrative access unless it is genuinely required. Management should pass through a dedicated network, VPN or tightly restricted source list, with named accounts and monitored changes. Confirm that the device remains within vendor support and continues to receive security updates.

AI supported the research but did not replace researchers

CERT Polska used GPT-5.5-cyber and GPT-5.6-sol models inside an isolated lab to automate virtual-machine operations, compare versions, analyse protocols and build tests. The environment contained 40 CHR virtual machines, 39 snapshots and 24 RouterOS releases.

This does not mean a model independently “found and published the vulnerability”. Researchers selected the scope, prepared the environment, supervised experiments, validated results and conducted coordinated disclosure. The practical lesson for organisations is about process, not AI marketing: automation should operate in an isolated environment, against controlled targets and under human accountability.

Source facts and Breachroad conclusions

The CERT Polska active-exploitation advisory confirms fixed releases, observed exploitation, indicators and response guidance. Its MikroTrick technical analysis explains the two-vulnerability mechanism, attack artefacts, disclosure process and use of LLMs.

The inventory model, supplier questions and business prioritisation are Breachroad conclusions. Organisations should connect this response to a durable vulnerability management process and a method for prioritising critical vulnerabilities. A compromised-edge-device scenario is also a strong candidate for an incident-response tabletop exercise.