Two vulnerabilities in MikroTik RouterOS SSH, when combined, allow attackers to gain full administrative control of Internet-exposed routers without a password, SSH key, or end-to-end authentication.
See also: MikroTik botnet uses SPF DNS records to spread malware
As previously reported, CERT Polska warned on September 5 that attackers were exploiting vulnerabilities in RouterOS to take over devices whose SSH service was accessible from public networks. That warning confirmed the exploit and called for an immediate fix, but it did not specify which two vulnerabilities formed the chain or explain how they were combined. This latest analysis provides both.
SSH requires three steps in sequence: it establishes an encrypted connection, authenticates the user, and only then allows the client to open a session and execute commands. The server sends a specific message (SSH_MSG_USERAUTH_SUCCESS) to confirm that the authentication has passed.
CVE -2026-67279 interrupts this sequence. If a client initiates an SSH key renegotiation during the authentication step, the vulnerable RouterOS proceeds directly to the command phase when the renegotiation is complete, without ever verifying the user's identity. The vulnerability does not create an authenticated session or grant any privileges on its own, but it allows an unauthenticated client to reach a stage that would otherwise require a full login.
CVE -2026-86060 turns this access into full administrative control. RouterOS launches a login program (/nova/bin/login) that receives the username and a privilege level from the SSH daemon as command-line arguments, without first checking the username. A value that begins with a hyphen is treated as a program option rather than a name. The attacker sends -2 as the username. The login program treats this as a command to read its identity and privilege level from file descriptor 2, which points to the terminal created by the SSH session.
Through the SSH channel, the attacker has already typed a chosen username and privilege value for full administrative access to this terminal. The login program accepts both and opens a fully privileged console.
See also: OVHcloud blames DDoS attack on MikroTik botnet
Proof of operation before repair
The chain leaves a characteristic trace in the device logs: a failed login attempt for user -2. CERT Polska reports that logs matching this pattern appeared on the MikroTik forum as early as September 2, a day before the fixes became available, and the team believes that the chain was exploited before MikroTik released the fixes.
A diagnostic report on the MikroTik forum shows the attack sequence on a device: authentication rejected for -2, forced renegotiation, jump to the channel phase, and an execution request that attempts to create a user named ops with full privileges. The SSH process crashed before the command was completed on this device.
Other reports confirmed that the ops account was successfully created on affected devices. In some incidents, CERT Polska found diagnostic file creation followed by data transfers to an attacker's IP address, strongly indicating that configuration data was copied to the attacker's infrastructure.
The MikroTrick chain is CVE-2026-67279 combined with CVE-2026-86060. Some publications have incorrectly included a third vulnerability, CVE-2026-67276, which CERT Polska says is a separate SSH vulnerability that allows an attacker to forge an RSA key to log in as an existing user. This vulnerability requires knowledge of the account name and its public key and provides access only to that account. CISA added CVE-2026-86060 to its list of known exploits on September 10, independently confirming the active exploitation of the argument injection vulnerability.
The chain requires SSH to be accessible to the attacker. MikroTik says its default home configuration does not expose SSH to the internet, but administrators who have changed their firewall rules or are managing devices via SSH from untrusted networks are at greater risk. No authentic count of compromised devices has been published.
See also: AWS Security Hub Extended: New Supply Chain Security Category with Chainguard and Socket
The fix prevents the attack but does not remove changes an attacker made before the update. After the update, users should check their configurations and logs for any unauthorized changes.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
