MikroTik RouterOS Vulnerabilities Under Active Exploitation, Patch Immediately

The CERT Polska team has confirmed active exploitation of a vulnerability chain affecting MikroTik RouterOS devices. The attack chain, dubbed MikroTrick, combines two flaws and grants full administrative control over devices with SSH exposed to the internet. Patches are available in versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21.

MikroTik released those updates following a coordinated disclosure by CERT Polska, which identified six vulnerabilities across the RouterOS SSH server and client, bandwidth-test service, X.509 certificate handling, and WebFig interface. The patches, according to CERT Polska, stop the observed attacks. Administrators should update immediately and then audit their configurations.

Critical Vulnerabilities

CVE-2026-67276 carries a CVSS score of 9.2. RouterOS failed to properly verify RSA public keys used for SSH authentication, specifically by not comparing the full key assigned to a user. An attacker who knew a username and the public modulus of that user’s key could construct a different key and authenticate over SSH without the corresponding private key. The resulting session carried the same privileges as the targeted account.

CVE-2026-86060 also scores 9.2. RouterOS mishandled usernames beginning with disallowed characters in the SSH login process. By sending a crafted username, an attacker could escalate to full administrative privileges.

CVE-2026-67277 scores 8.8. The bandwidth-test service allowed an unauthenticated connection to reach a state meant only for logged-in users. Combined with an uninitialized data disclosure from the packet buffer and an integer underflow in size validation, this opened a path to kernel memory leakage or a remote denial-of-service causing a system restart.

Attack Indicators

CERT Polska began observing attacks within days of identifying the vulnerabilities. The attacks targeted RouterOS devices with SSH accessible from public networks. According to the team’s analysis, successful exploits originated from IP address 82.192.72.4. Attempts were also linked to 103.102.31.18. Both IP addresses have been associated with the MikroTrick chain since at least September 2.

Exploitation leaves traces in the RouterOS logs. Indicators include:

login failure for user -2 from ip via ssh

user name added by ssh:-2@ip

The presence of a privileged account named ops also signals compromise. These artifacts demand immediate investigation, though their absence does not exclude unauthorized activity.

Flagged Mechanism

Beginning with these fixed releases, MikroTik introduced the Flagged mechanism. When RouterOS starts, it scans the configuration for known signs of unauthorized changes. Detected entries are disabled, a critical message is written to the log, and the Flagged marker is set. The mechanism identifies selected compromise traces only. The absence of the marker does not mean the device is safe. MikroTik documented the procedure in its Flagged mechanism documentation.

Administrators should check logs for the device compromise message and the Flagged marker by running /system/device-mode/print. Configuration review should look for unknown users, scripts, scheduler tasks, proxy servers, and tunnels.

MikroTik took an unprecedented step alongside the patches: for the first time, the company sent push notifications through the MikroTik app to users who had it installed.

Immediate Mitigations

If patches cannot be applied immediately, administrators should disable SSH, WWW/WWW-SSL, and the bandwidth-test server or restrict access to trusted management networks only. They should also avoid initiating TLS connections from unpatched devices and refrain from using the built-in /system ssh and /system ssh-exec clients, particularly when traffic crosses untrusted networks. These are temporary mitigations, not substitutes for updating.

Incident Response

Where compromise indicators appear, the device should be isolated from the network. Before any reset, logs and configuration should be secured following the steps in the CERT Polska article MikroTik – securing logs and configuration. The Flagged marker should not be cleared until analysis is complete and material is preserved.

After securing evidence, administrators should reset the device to factory settings, restore from a known-good configuration, and rotate all passwords, keys, and secrets. A configuration backup from a potentially compromised device should not be restored blindly.

Discovery Process

The vulnerabilities were discovered by the CERT Polska team using GPT-5.5-cyber and GPT-5.6-sol models through the OpenAI Government and Trust Agency Collaboration (GTAC) program. Researchers set up an isolated laboratory with MikroTik hardware, system architecture documentation, and safe testing protocols. The models automated machine creation and restoration, version comparison, RFC and binary analysis, and vulnerability confirmation scripts. Modeling protocols as state machines and testing what happens when steps are skipped, repeated, or reordered proved especially effective.

The work required substantial human input throughout. Researchers prepared RouterOS context, designed the laboratory and supporting tools, selected research directions, and then fully verified every result, ruled out false conclusions, and assessed real-world impact. The models accelerated analysis and hypothesis exploration but did not replace those stages.

The disclosure was expedited because patched RouterOS packages had already become public, allowing the security community to reconstruct some of the fixed bugs. CERT Polska limited this advisory to information administrators need and withheld exploit code or details that would simplify automation of exploitation.