The Username Was a File Descriptor: Inside MikroTrick

login failure for user -2 from <ip> via ssh

Seconds later, a second record changes the meaning of the first:

user ops added by ssh:-2@<ip>

Those are not synthetic strings invented for a threat-hunting exercise. CERT Polska reported them while documenting attacks against internet-reachable MikroTik RouterOS devices. The researchers confirmed that a vulnerability chain they named MikroTrick was being used to obtain full control, and that patched releases stopped the observed attacks.[1]

The small detail is -2. It looks like a bad username. In the wrong parser, it is not a username at all.

A username that changed grammars

CVE-2026-86060 sits in the RouterOS SSH login path. CERT Polska describes a crafted username beginning with a prohibited character reaching the login helper and changing the trusted RouterOS policy mask. The resulting session receives full administrative privileges. Affected branches were fixed in 6.49.21, 7.23.4, and 7.24.2.[1][2][5]

This is more precise than calling the issue “insufficient username validation.” The dangerous transition happens when one component treats a value as identity data and the next component interprets the same bytes as control syntax.

Conceptually, the flow looks like this:

SSH identity string
    -> authenticated identity passed to a login helper
    -> leading "-" selects an internal argument form
    -> internal form reads replacement fields
    -> replacement policy becomes the session authority

The outer component has already decided what the value means: this is the account name associated with a particular authorization policy. The inner component still accepts a private grammar intended for trusted callers. Once untrusted data crosses that boundary, identity and authority can be rebound.

That is a confused-deputy problem implemented through argument confusion. It belongs in the same threat model as a path that becomes an option, a filename that becomes a template, or a tenant-supplied object ID that becomes an authorization decision. Our earlier analysis of identities and trust boundaries applies directly: the trust level of a value must not increase merely because it crossed a process boundary.

The safe mechanism lab

For this article, I built and executed a vendor-neutral local model. It opens no socket, uses no RouterOS image, and contains no product exploit payload. The vulnerable function accepts an identity argument. If that argument starts with -<number>, it treats the number as a file descriptor and reads two NUL-delimited fields from it: a replacement identity and a replacement policy.

def vulnerable_login(identity_arg, authenticated_policy):
    if identity_arg.startswith("-") and identity_arg[1:].isdigit():
        identity, policy = read_transport(int(identity_arg[1:]))
        return Session(identity, policy, "fd-transport")
    return Session(identity_arg, authenticated_policy, "argv")


def fixed_login(identity_arg, authenticated_policy):
    if not valid_identity(identity_arg):
        raise ValueError("invalid identity input")
    return Session(identity_arg, authenticated_policy, "argv")

The test sends replacement-user\0full\0 through a local pipe. The vulnerable model returns:

{
  "identity": "replacement-user",
  "policy": "full",
  "source": "fd-transport"
}

The fixed model rejects the ambiguous identity before the internal parser sees it. Negative controls also reject a leading space and control bytes while preserving an ordinary analyst identity with its original read-only policy.

This lab proves the mechanism, not RouterOS exploitability. It does not reproduce SSH framing, vendor binaries, authentication behavior, or the field campaign. That boundary matters because public reporting intentionally withholds details that would make automated attacks easier.[1]

The attack chain, with the evidence boundary intact

MikroTrick is important because CVE-2026-86060 is not being evaluated in isolation. CERT Polska says two RouterOS vulnerabilities were combined for unauthenticated full control of devices exposing SSH to public networks. Its public advisory documents the privilege manipulation, the observed -2 attribution, creation of a highly privileged ops user, and successful prevention after patching.[1]

The operator’s logic is economical:

1. Find a management plane that should never have been public. External exposure inventory is the prerequisite, not the exploit. The discovery methods in our Shodan offensive security guide are useful here when applied to assets you own.
2. Reach an SSH state in which the crafted identity is accepted far enough to invoke the login helper.
3. Trigger the grammar collision so the trusted policy value is replaced.
4. Use administrative context to establish persistence or traffic-handling capability. In observed activity, the useful signal was not merely login success. It was configuration mutation attributed to ssh:-2@<source> followed by the ops account.[1]

CISA added CVE-2026-86060 to the Known Exploited Vulnerabilities catalog on 10 September 2026, with a 13 September remediation due date for covered organizations. The catalog lists ransomware use as unknown, which should not be misread as absence of hostile exploitation.[4]

A second entry, CVE-2026-67277, shows why RouterOS review should extend beyond SSH. The bandwidth-test service accepted a related connection before the primary session completed authentication. That state error exposed uninitialized kernel packet-buffer data and, through a separate unsigned underflow, could produce unusually large fragmented output and restart the kernel.[2][6]

The common research move is worth keeping: model protocols as state machines, then test what happens when a stage is skipped, repeated, or reordered. CERT Polska reports that supervised AI agents helped automate version comparison, binary analysis, lab restoration, and hypothesis testing, but every claim still required clean-state repetition, negative controls, and human impact assessment.[1] That is credible AI-assisted vulnerability research. A model generates branches; the laboratory decides which branch is real.

Detection: correlate the boundary crossing

A single failed login is cheap noise. A sequence is evidence.

Start with edge telemetry: SSH exposure, newly observed source addresses, and sessions reaching routers outside the expected management network. Join that with RouterOS logs containing the unusual -2 identity or changes attributed to ssh:-2@<source>. Then inspect state for an unknown ops account, any unexpected full-policy user, scripts, scheduler tasks, SOCKS or web proxies, and tunnels. CERT Polska associated successful activity with 82.192.72.4 and attempts with 103.102.31.18, while warning that absence of those artifacts does not exclude compromise.[1]

On a patched device, defenders can collect a focused snapshot without changing state:

/system/resource/print
/system/device-mode/print
/user/print detail
/system/script/print detail
/system/scheduler/print detail
/ip/proxy/print
/ip/socks/print
/log/print where message~"ssh:-2|Flagged|user ops"

Treat flagged: yes as an incident indicator, not an automated cleanup receipt. MikroTik says fixed RouterOS releases inspect startup state for recognized compromise artifacts, write a critical log message, and set Flagged status. Both the vendor and CERT Polska emphasize that flagged: no does not prove safety.[1][3][7]

For fleet-scale detection, retain the raw router timestamp, source address, actor string, command or object changed, and configuration diff. Normalize later. The literal attribution string is valuable because a generic SIEM rule that extracts only “SSH success” will discard the parser artifact that makes this chain distinctive.

Patch, then decide whether the router is still trusted

MikroTik’s fixed releases are 7.24.2, 7.23.4, 6.49.21, and 7.25beta3 or later. The vendor recommends removing SSH from untrusted networks and using a management VPN such as WireGuard rather than exposing management ports.[3]

If compromise indicators exist, patching is containment, not eradication. Preserve logs and configuration before reset. Isolate the device, rotate administrative passwords, keys, and other secrets, then rebuild from a trusted configuration rather than restoring a full backup from the suspect router. CERT Polska explicitly recommends factory restoration after evidence collection when compromise is indicated.[1] The operational pattern mirrors our patch, hunt, and harden workflow: close the known entry point, search for durable state, and recover trust instead of equating a new version number with a clean system.

Strategic takeaways

The bug is not interesting because -2 is clever. It is interesting because an internal compatibility mechanism survived behind a security boundary and accepted data with two meanings. Mature reviews should trace every identity, pathname, option, and policy field across process boundaries, then ask whether the receiving parser exposes a richer grammar than the sender intended.

For operators, internet-exposed management planes remain a high-confidence path to device takeover. Inventory and restrict them before a CVE arrives. For defenders, preserve product-native attribution fields and configuration history. That is where parser confusion becomes visible. For AI-assisted researchers, automate state exploration and binary comparison, but require the same controls CERT Polska described: reproducible clean-state tests, negative controls, and a human decision about impact.

The first log line looked like a failed login. The second showed that the username had become a control channel.

Sources

• [1] https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited: Critical vulnerabilities in MikroTik RouterOS are being actively exploited
• [2] https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve: Vulnerabilities in MikroTik RouterOS software
• [3] https://mikrotik.com/supportsec/september-2026-vulnerability: MikroTik September 2026 vulnerability
• [4] https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-86060: CISA Known Exploited Vulnerabilities Catalog: CVE-2026-86060
• [5] https://nvd.nist.gov/vuln/detail/CVE-2026-86060: NVD CVE-2026-86060
• [6] https://nvd.nist.gov/vuln/detail/CVE-2026-67277: NVD CVE-2026-67277
• [7] https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode: MikroTik RouterOS Flagged status documentation