Introduction

On 3 September 2026, MikroTik released patches almost simultaneously for several maintained RouterOS branches: 7.25beta3, 7.24.2, 7.23.4, and 6.49.21, and recommended installing a patched version as soon as possible. The vendor described the release as an important security update but temporarily withheld the vulnerability details to give administrators time to update their devices.

Some of the fixes addressed vulnerabilities discovered by Sławomir Rozbicki of CERT Polska, which were reported to the vendor through coordinated vulnerability disclosure (CVD). We had planned to synchronize the publication of their details with the release of the updates, but the new versions were released sooner than we had expected. The vendor also used push notifications in the MikroTik app to emphasize the need to upgrade.

The urgency of the announcement and the lack of specific information about the threats prompted extensive speculation on MikroTik's official forum. At the same time, users began posting device logs suggesting that attacks might have started before the patches became available.

Identifying CVE-2026-86060

When the new RouterOS versions became available, we began patch diffing to determine whether the vendor fixed the vulnerabilities we had reported. The packages also contained changes to mechanisms that were not covered by our reports.

Patched RouterOS versions validated the username before passing it to the /nova/bin/login application. The scope of this validation suggested that, before the patch, the username could affect how the program interpreted its arguments. The decompiled function looked as follows:

We also identified changes to the Flagged mechanism, which detects configuration entries that may indicate compromise. A new rule checked at startup for an ops account belonging to the privileged full group. If the condition was met, RouterOS disabled the account, logged a warning, and set the Flagged status. The introduction of such specific indicators of compromise (IoCs) could mean that the vendor had at least partial knowledge of the attacks.

We then examined logs published by administrators on the MikroTik forum and Reddit. Two distinctive entries appeared in multiple reports:

login failure for user -2 from 82.192.72.4 via ssh
user ops added by ssh:[email protected]

We noticed an apparently contradictory sequence in these logs: a failed login attempt for user -2, followed by the creation of the ops account within the same session.

Combining this information with the results of patch diffing allowed us to identify a new critical vulnerability within an hour, assign it the CVE-2026-86060 identifier, and provide the vendor with the details and a working proof-of-concept script.

Combined with CVE-2026-67279, the vulnerability allowed an attacker to obtain full administrative privileges without knowing a password, possessing an SSH key, or completing authentication. We named this chain MikroTrick.

CVE-2026-67279

SSH provides several administrative capabilities, including remote terminal access, command execution, file transfer, and connection tunneling within an encrypted communication channel. The protocol consists of three successive layers:

1. transport,
2. user authentication,
3. connection and channel handling.

After a TCP connection is established, the client and server negotiate cryptographic algorithms and perform a key exchange to establish a shared secret. The server signs the exchange parameters with its host key, allowing the client to verify the server's identity. When connecting for the first time, clients often follow the Trust on First Use (TOFU) model. Both sides then derive key material for further communication from the shared secret. From that point, their communication is encrypted and protected against modification. This stage authenticates the server to the client, but not yet the user to the server.

The client then authenticates the user with one of the permitted methods, such as a password or public key. If authentication succeeds, the server sends SSH_MSG_USERAUTH_SUCCESS. Only then does channel handling begin, allowing the client to access a shell, execute a command, or use other administrative functions according to the privileges assigned to the SSH user. This division is specified in RFC 4253, RFC 4252, and RFC 4254.

After the initial key exchange, either side may initiate another one, known as a rekey. This changes the transport keys without terminating the TCP connection or altering the state of higher-layer protocols. Rekeying usually occurs after a specified amount of data has been transferred or a certain time has elapsed, but the protocol also permits it before user authentication is complete.

Vulnerable versions of the RouterOS SSH server handled a rekey initiated during user authentication incorrectly. When the rekey finished, the server unconditionally moved from the temporary rekey state to channel handling instead of resuming the interrupted authentication. As a result, it accepted a session channel and the associated requests despite never having sent SSH_MSG_USERAUTH_SUCCESS.

The vulnerability did not establish an authenticated identity or assign any privileges. It did, however, allow the connection to move from user authentication to channel handling, which was a prerequisite for exploiting CVE-2026-86060.

CVE-2026-86060

After successful authentication, a client may open a session channel. Exploiting CVE-2026-67279 bypasses this requirement. To create a remote console, the client then normally sends pty-req followed by shell. The server creates a pseudoterminal and starts a child process attached to it. In RouterOS, that process is /nova/bin/login, invoked according to the following pattern:

/nova/bin/login -ssh -trace <trace> -h <client address> [-c <command>] <username> <policy mask>

During normal operation, the last two positional arguments contain the authenticated user's name and effective policy mask, passed as a decimal integer. The login program does not repeat password or key verification. It trusts the decision made by its parent process and creates the console on that basis.

The username is sent in SSH_MSG_USERAUTH_REQUEST before authentication is complete and stored by the sshd process. sshd subsequently passes it without validation as an element of the argv array supplied to login. A value beginning with - is interpreted as a program option rather than a username.

The login application recognizes a special -N syntax in which the integer N identifies a file descriptor. When it encounters such an argument, the process reads a record containing two NUL-separated fields from the selected descriptor. The first field is interpreted as a username and the second as an effective policy mask when the -ssh argument is present. After the read completes, the parser closes the selected descriptor and continues processing the remaining command-line arguments.

Using -2 as the username therefore causes login to read these values from file descriptor 2, which refers to the pseudoterminal established earlier. File descriptors 0, 1, and 2 of the login process all refer to the same pseudoterminal and therefore share its input queue. This allows an attacker to send a value through the SSH channel that login then uses as the effective policy mask.

MikroTrick

Combining the two vulnerabilities resulted in full unauthenticated access to the administrative console. CVE-2026-67279 allowed an unauthenticated client to create a session channel, while CVE-2026-86060 allowed it to supply login with an attacker-controlled policy mask.

Exploiting both vulnerabilities in this way leaves a log entry for a failed login attempt by user -2, matching the public log entries quoted earlier. This leads us to believe that MikroTrick was exploited before the patches were released.

Some publications incorrectly associated CVE-2026-67276 with the MikroTrick chain. It is a separate vulnerability that allows an attacker to impersonate a user authenticated with an RSA key. Exploitation requires the account name and the modulus of the public key assigned to it, while a successful attack provides access only to that account. This makes the vulnerability significantly less suitable for a mass attack that works regardless of device configuration.

An LLM Agent in the Research Lab

We conducted the RouterOS research using GPT-5.5-cyber and GPT-5.6-sol models with reduced refusal thresholds through our access to the OpenAI GTAC program. CERT Polska also operates its own infrastructure for running large open-weight models locally, including GLM, DeepSeek, Qwen, and the Polish model PLLuM. The effectiveness of the RouterOS research depended on an isolated laboratory in which the agent could control virtual machines autonomously and on carefully defining the scope of each experiment.

Through libvirt, the agent prepared virtual machines, created and restored snapshots, ran tests, and collected artifacts. By the end of the research, the lab contained 40 CHR virtual machines, 39 snapshots, and 24 RouterOS releases ranging from 6.43.11 to 7.25beta3. Before each experiment, the device was configured and placed in the state needed to test the hypothesis. The LLM created and operated the tools that performed these tasks, replacing work that previously had to be done manually.

The agent performed static analysis of binaries extracted from the RouterOS CHR x86 filesystem using radare2 and Ghidra. It compared the results with documentation for the protocols under study, particularly the relevant RFCs. By comparing successive releases, we could determine which version introduced a bug and which version fixed it.

The models were particularly effective at analyzing protocols as state machines. They systematically tested what happened when protocol stages were repeated, messages were skipped or reordered, or dependent channels were opened prematurely. One such test involved a rekey before SSH authentication had completed and led to the discovery of an invalid state transition.

After the patches were released, LLM agents monitored the MikroTik forum, Reddit, and other public sources, helping us track reports of exploitation and attempts to reconstruct the exploit.

The most time-consuming parts were preparing the context (precise information for the agent) and the laboratory, resolving ambiguous results, and validating findings against actual RouterOS releases. We considered a vulnerability confirmed only after obtaining repeatable results, performing negative tests, analyzing artifacts, and comparing several versions of the system.

Attacks in the Wild

The earliest publicly available attack logs dated from 2 September, before the patches were released. Together with reports received by CERT Polska, they allowed us to reconstruct how the observed threat actor operated.

Public reports contained a recurring set of indicators: connections from 82.192.72.4, an authentication attempt as -2, and the creation of a fully privileged ops account. A diagnostic report published on the MikroTik forum documented rejected authentication, rekeying, channel opening, and command delivery through exec. On that device, the attack ended with the SSH process crashing. Another report confirmed that an administrative account had been created successfully on devices configured to use only SSH keys and strong-crypto, while another administrator found the account on multiple managed devices.

Logs published on the trzepak.pl forum documented the creation of a RIF diagnostic file and the transfer of data to 82.192.72.4 using the fetch command. A similar sequence was published on Reddit. In both cases, the transfer occurred shortly after the file was created, strongly suggesting the exfiltration of diagnostic files.

Patch Analysis

After the patches were published on 3 September, administrators began updating their devices while independent researchers analyzed the new packages. Key elements of the vulnerabilities were publicly reconstructed within days.

Administrators noted on the MikroTik forum that some devices could be updated only with physical access or during a maintenance window. Reports of regressions also meant that the new version had to be tested and a rollback plan prepared before wider deployment.

The NPK packages allowed direct comparison between files from vulnerable and patched versions. A public article analyzing these differences appeared on 4 September at 03:22 UTC (npratley.net). The author described the work as AI-assisted and verified in a laboratory. The first version of the analysis did not reconstruct the complete MikroTrick chain, but it identified the principal changes to the SSH server implementation and pointed to areas for further research.

By 5 September, the name -2 had been publicly linked to a file descriptor in the login program. Independent researchers also reported reproducing unauthenticated SSH access without publishing the full exploitation procedure (Reddit, MikroTik forum, further analysis). The available material already contained most of the information needed to reconstruct the attack.

We began publishing the CVE records on 5 September at 20:00:55 UTC (CVE-2026-67276, CVE-2026-86060). At that point, keeping the details confined to CVD channels no longer presented a meaningful obstacle to those reconstructing the exploit, but it did restrict the information available to administrators.

On 10 September, two vulnerabilities we had discovered, CVE-2026-67277 and CVE-2026-86060, were added to CISA's Known Exploited Vulnerabilities (KEV) Catalog with a three-day remediation deadline.

Conclusions

The speed of LLM-assisted patch analysis is blurring the line between releasing an update and publishing the technical details of a vulnerability. In the case of MikroTrick, the key elements of the flaws were identified publicly within days. The lower cost of code analysis did not, however, reduce the time required to test and deploy updates or to examine systems for evidence of prior compromise.

This asymmetry does not justify delaying patches, but vendors should expect analysis of their changes to begin as soon as they are released and to involve AI tools. This places greater responsibility on vendors to provide reliable information alongside updates about the attack surface, available mitigations, indicators of compromise, and detection rules, allowing users to take defensive action sooner.