MikroTrick: RouterOS under active attack
- Two chained RouterOS flaws: CVE-2026-67276, an SSH authentication bypass from incomplete RSA public key validation, and CVE-2026-86060, an SSH privilege escalation through crafted usernames. Chained, they give full control of the device.
- Poland’s CERT confirmed active exploitation against devices with SSH reachable from public networks.
- ShadowServer counted 122,500 MikroTik devices with an exposed SSH interface as of September 5.
- Fixed September 3 in 7.25beta3, 7.24.2, 7.23.4, and 6.49.21.
- The bugs were found by a national CERT with help from GPT-5.5-cyber and GPT-5.6-sol, disclosed responsibly, and the fixes were validated before publication.
Indicators of compromise: log entries showing login failure for user -2 and user <name> added by ssh:-2@<ip>, and a highly privileged ops account. Poland’s CERT warns that the absence of these markers is not proof of a clean device.
CIS Controls: 12.1 (keep network infrastructure up to date), 12.6 (secure network management protocols), 7.3 and 7.4 (automated patch management), 8.2 and 8.5 (collect audit logs, since the IOCs only exist if you kept them).
The management plane does not belong on the internet
- MikroTik’s interim guidance for anyone who cannot patch: restrict or disable externally accessible SSH, WWW/WWW-SSL, and bandwidth-test services.
- 122,500 exposed SSH interfaces is the actual vulnerability. The CVEs are this month’s reason it mattered.
- It is the whole control plane, not just SSH: web UI, API, cloud management, SNMP, and vendor remote-support channels all count.
- The pattern that works: out-of-band or VPN-only management, source-IP restrictions, dedicated admin workstations, and management never reachable from the same interface as user traffic.
- “I need remote access for support” is answered by a VPN or a jump host, not a public port.
CIS Controls: 12.2 (secure network architecture), 12.3 (securely manage network infrastructure), 12.7 (remote devices use a VPN into enterprise AAA), 12.8 (dedicated resources for administrative work), 4.6 (securely manage assets), 4.8 (disable unnecessary services), 6.5 (MFA for administrative access), 5.4 (dedicated admin accounts), 13.5 (check device health before granting remote access).
The vendor’s forensic problem, and why disclosure fixes it
- When a customer reports a breach, the vendor is working backward from an outcome with no reproduction steps. It has to separate three possibilities: customer misconfiguration, credential compromise on the customer side, or a real product defect.
- Those three look nearly identical in most log data. The customer’s incentive is to believe it is a defect, the vendor’s is to believe it is misconfiguration, and neither is necessarily acting in bad faith.
- A bug bounty submission inverts all of that. The vendor gets a working proof of concept, reproduces it on demand, finds the exact code path, fixes it, and validates the fix before anyone is exploited.
- Responsible disclosure converts an unbounded investigation into a bounded engineering ticket.
- Log retention is the hinge. Whether anyone can answer the question at all depends on whether the customer kept logs. The RouterOS IOCs above are log strings.
CIS Controls: 16.2 (a process to accept and address software vulnerabilities, which is the bug bounty control), 16.1 (secure application development process), 16.3 (root cause analysis), 18 (penetration testing), 8.2, 8.5, 8.9, and 8.10 (collect, centralize, and retain logs), 17.2 and 17.3 (contacts and a process for reporting incidents).
SonicWall: what happens when nobody has a clean answer
These are allegations in a complaint. The disclosure revision is documented; the API claim is Marquis’s assertion.
- Marquis, a fintech serving hundreds of banks and credit unions, sued SonicWall in the Eastern District of Texas in February 2026 over a ransomware attack on its network.
- Marquis alleges attackers used firewall configuration data stolen from SonicWall’s cloud backup service, including scratch codes, to get into its network.
- The documented part: in mid-September 2025 SonicWall said fewer than 5% of customer firewall configuration backups were taken. In October it conceded every customer’s backup files were stolen.
- Marquis alleges the root cause was a February 2025 API change that let attackers pull backup files without proper authentication by guessing predictable firewall serial numbers.
- Marquis says SonicWall has not provided non-public root cause information and expects to learn more through litigation.
- At least 400,000 people are known affected per the Texas AG listing, and the number is expected to rise.
- When a vendor cannot or will not produce a root cause, the customer’s remaining discovery mechanism is a lawsuit. That is the worst version of vulnerability disclosure.
CIS Controls: 15.1, 15.2, 15.4, and 15.5 (service provider inventory, policy, contract requirements, and assessment), 3.3 and 3.11 (protecting the data in those config backups), 11.2 and 11.3 (protecting backups, since the backup service was the attack surface), 17.4 (incident response process), 16.3 (root cause analysis, and what it looks like when it does not happen).
UniFi: the same year, the opposite outcome
- May 2026: three max-severity UniFi OS flaws, CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910, plus CVE-2026-33000 and CVE-2026-34911, all reported through Ubiquiti’s HackerOne program. Censys was tracking nearly 100,000 internet-exposed UniFi OS endpoints at the time.
- July 2, 2026: Bulletin 066 disclosed 25 vulnerabilities across UniFi Connect, Talk, Access, Protect, Network Application, and UniFi OS. The worst was CVE-2026-50746 at CVSS 10.0, seven were 9.0 or higher, and all 25 had fixes available at disclosure.
- Ubiquiti’s program pays roughly $100 to $25,000 and takes submissions through HackerOne or security@ui.com.
- Ubiquiti published far more CVEs than SonicWall, and that is evidence the process works, not evidence the product is worse. Counting CVEs punishes vendors who disclose and rewards vendors who stay quiet.
- Would you rather buy from the vendor with 25 published CVEs and fixes, or the one with three published CVEs and a lawsuit?
CIS Controls: 16.2 (the same control, working), 7.1 and 7.2 (your own vulnerability management and remediation, because 25 CVEs is only good news if you patch), 12.1, 7.3 and 7.4.
What a functioning disclosure program looks like
- Vendor side: a published security contact, a stated response SLA, safe harbor language so researchers are not threatened with legal action, coordinated disclosure timelines, and credit for reporters.
- MikroTik noted not all configurations are affected and withheld technical details to give users time to patch. Whether that is responsible or slows defenders is a fair debate.
- The counterargument: duplicate submissions, lowball payouts, scope disputes, researchers going public when ignored, and vendors who answer disclosure with legal threats.
- Buyer side: vendor security process belongs in your evaluation. Does the vendor have a published VDP? Do they credit researchers? What did their last disclosure timeline look like?
CIS Controls: 16.2, 15.4 (security requirements in service provider contracts), 15.5 (assess service providers), 17.2.
Three things to do before Monday
- Inventory every device with a management interface reachable from the internet. That is CIS 1.1 and 12.2, and it is the whole episode in one task.
- Patch RouterOS if you run it, and check the CERT IOCs even if you did.
- Check whether the vendors you buy from publish a vulnerability disclosure policy. If they do not, that is now a purchasing signal.