MikroTik's Newest Router Bugs Were Found by an AI Model. Its Last Two KEV Listings Fueled the Mēris Botnet.
CVE-2026-86060 and CVE-2026-67276 chain into what CERT Polska calls MikroTrick: an unauthenticated attacker forges an SSH login, then escalates to full admin with a username no login screen should ever accept. MikroTik patched it in silence — a researcher reverse-engineered the fix from a binary diff a day later, and attackers had already been in for a day before that.
CVE Tools8 min read
On September 2, 2026, someone started breaking into MikroTik routers over SSH using a bug that had no patch, no CVE, and no name. On September 3, MikroTik shipped one anyway — buried in a changelog line that read "ssh - refactor SSH internal processes and improved system stability." On September 4, a researcher who didn't buy that explanation diffed the binaries and published working exploit code. On September 5, CERT Polska confirmed the rest of the story: six new RouterOS vulnerabilities, two of them chainable into a full unauthenticated device takeover, already under attack before the patch existed.
The MikroTrick chain
CERT Polska named the exploit chain MikroTrick. It's two bugs, used together: CVE-2026-67276 lets an attacker who knows an authorized user's RSA public key modulus forge a valid SSH signature and open a command channel as that user — without ever having the private key, because RouterOS checks the key's type and modulus but never checks the exponent. CVE-2026-86060 then takes that session the rest of the way: RouterOS's SSH server hands the username to a legacy internal login helper as a positional argument, and if that username is the literal string "-2", the helper treats it as a file-descriptor number instead of a name — reading a full administrative policy mask straight off the terminal input stream. Chain the two together and you get root-equivalent RouterOS control from an attacker who supplied no password and no private key.
MikroTrick: from SSH connection to full admin
- Attacker opens an SSH connection
- Forges an RSA signature with exponent = 1 (CVE-2026-67276) — RouterOS checks key type + modulus, never the exponent
- Opens a command channel as the target user — no private key used
- Logs in again with the literal username "-2" (CVE-2026-86060)
- Legacy login helper reads the policy mask off the terminal file descriptor
- Full RouterOS admin — no password, no private key, ever
| CVE | CWE | CVSS (our index) | In CISA KEV (our index) | Role in the chain |
|---|---|---|---|---|
| CVE-2026-67276 | CWE-347 — Improper Signature Verification | Unscored as of writing | No | Forges an SSH login as any user without their private key |
| CVE-2026-86060 | CWE-88 — Argument Injection | 9.8 | Yes | Escalates the session to full admin via the username "-2" |
| CVE-2026-67277 | CWE-306 — Missing Authentication for Critical Function | 8.2 | Yes | Separate, unauthenticated kernel memory leak/crash via the bandwidth-test service |
Found by GPT-5.5-cyber, verified by a human
Multiple outlets covering CERT Polska's disclosure — Industrial Cyber, Cybernews, CyberInsider and BleepingComputer among them — report that CERT Polska researcher Sławomir Rozbicki found these bugs using OpenAI's GPT-5.5-cyber and GPT-5.6-sol models, through what's been described as the team's access to an OpenAI research-collaboration program. The models reportedly automated version comparison, protocol analysis and binary analysis inside a lab environment the researchers scoped and supervised; every candidate finding was then validated by hand against real RouterOS hardware before being reported. We haven't independently verified CERT Polska's own technical write-up on the methodology — it's referenced but sits behind a companion post we couldn't fetch directly — so treat the AI-tooling detail as consistently reported by secondary sources rather than something we confirmed at the primary source.
A patch note that said nothing
To give time to update your systems, we are not currently publishing detailed information... for regular home device users the issue does not pose an immediate risk.
MikroTik shipped RouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 on September 3 with that as the only public explanation. Security researcher Nick Pratley didn't accept the changelog at face value. Rather than diffing the release byte-for-byte — which produces mostly noise once a binary shifts on rebuild — he compared the two versions at the symbol level.
- Downloaded both the patched (7.23.4) and prior (7.23.3) .npk installer packages
- Extracted the embedded squashfs filesystem from each
- Dumped exported symbols from the SSH-related binaries instead of diffing raw bytes
- Compared the two symbol lists and found one new function: validLoginParamInput
- Traced it back to RouterOS's legacy /nova/bin/login helper, which still treats a username starting with a dash as a file-descriptor number
Zero-day before the patch, PoC before the CVE
- Active exploitation beginsCERT Polska traces the first confirmed device takeovers to IP 82.192.72.4 — before any patch existed.
- MikroTik ships a silent patchRouterOS 7.25beta3, 7.24.2, 7.23.4 and 6.49.21 go out with a one-line changelog and no CVE, no advisory.
- A researcher reverse-engineers the fixNick Pratley diffs the patched and unpatched binaries, reconstructs three of the fixes, and publishes working Python proof-of-concept code — including a script forging an SSH login with a low-exponent RSA key.
- CERT Polska discloses six CVEsCERT Polska names the chain "MikroTrick," confirms active exploitation, and the records land in NVD.
- Scale checkShadowserver counts roughly 122,500 MikroTik devices with SSH open to the internet — Brazil, the US, Indonesia, the Czech Republic and Ukraine top the list.
- CISA adds two of the six to KEVCVE-2026-86060 and CVE-2026-67277 land on the Known Exploited Vulnerabilities catalog; CVE-2026-67276, the signature-forgery half of MikroTrick, doesn't — at least not in our own index as of writing.
MikroTik has been here before
This is only the third and fourth time a MikroTik CVE has ever made it onto CISA's KEV catalog, per our own index. The first two are the reason "unpatched MikroTik router" is shorthand for botnet fodder in the first place.
| CVE | Year disclosed | What it was | What happened to it |
|---|---|---|---|
| CVE-2018-7445 | 2018 | Buffer overflow in RouterOS's SMB service, tracing back to the leaked CIA "Chimay Red" exploit toolkit — unauthenticated RCE | Weaponized for cryptomining campaigns within months of disclosure |
| CVE-2018-14847 | 2018 | Unauthenticated WinBox-protocol directory traversal exposing RouterOS's user database | Patched in 2018 — then fueled the record-breaking Mēris DDoS botnet in 2021, when researchers still found 300,000+ vulnerable devices |
| CVE-2026-86060 / CVE-2026-67277 | 2026 | The MikroTrick SSH chain | Exploited in the wild before the patch even shipped |
The lesson from 2018 isn't that MikroTik patched slowly — both bugs got fixes the same year they were found. It's that a patch existing and a fleet of ISP- and SOHO-deployed routers actually running it are two different facts, three years apart. Mēris didn't need a zero-day in 2021; it needed a three-year-old, publicly known, already-patched bug and a very large number of devices nobody had rebooted onto the fix. MikroTrick starts from a worse position — under attack before day one — on a device base with the same update habits.
- Update to 7.25beta3, 7.24.2, 7.23.4 or 6.49.21 depending on your branch — the only fix for all three scored CVEs in this disclosure.
- Check the router's Log section for a "Flagged" entry noting possible prior compromise, and follow MikroTik's linked remediation steps if you see one.
- Audit for the "ops" user, unfamiliar Scheduler scripts, enabled Socks proxies, or unexpected tunnels — the same categories of indicator used in both this campaign and the 2018 Mēris takeovers.
- Move SSH, WebFig and the Work Place management interface off the public internet; both MikroTik and CERT Polska recommend a VPN (WireGuard) instead of direct exposure.
- If you run the bandwidth-test service, disable or restrict it — it's the separate vector for CVE-2026-67277, unrelated to the SSH chain.
CVE and KEV data as of 2026-09-13