MikroTik published an advisory on 20 October for a stack buffer overflow in the RouterOS SNMP service. One malformed SNMP request is enough to crash the SNMP process, and the default community string is accepted from any source address.
What happened
The flaw is CVE-2026-88464, in the code behind /snmp on UDP port 161. An SNMP version 1 or 2c request carrying an OID with many large sub-identifiers overflows a stack buffer and takes the SNMP process down.
No login is needed. A valid community string is the only credential, and the default public community is accepted regardless of where the packet came from. MikroTik describes the public report as a crash rather than code execution, but says it is treating the issue seriously.
Nobody has reported exploitation in the wild. This is a denial-of-service bug on an unauthenticated UDP service, not a remote shell.
Who is affected
RouterOS 7.20 and later, up to the fixed releases. RouterOS 6 and anything before 7.20 does not contain the vulnerable code.
- RouterOS 7.20 to 7.23.x devices with SNMP enabled and reachable by an attacker.
- Routers where UDP 161 is open to the internet, usually left over from a remote monitoring setup.
- Routers where SNMP is reachable from a guest Wi-Fi or flat office VLAN.
SNMP is disabled by default, so a router with no monitoring configured is not exposed.
What to do now
Upgrade to RouterOS 7.24 stable, 7.23.3 long-term, or any later release. If you cannot upgrade today, disable SNMP where it is not used and restrict it to the monitoring host where it is.
- Confirm the running version with
/system resource print, then upgrade and reboot. - If SNMP is not used at all, turn it off:
/snmp set enabled=no. - If it is used, scope the community to the monitoring address and drop UDP 161 from everything else in
/ip firewall filter. - Check that no WAN rule permits UDP 161 inbound, and review
/ip servicesfor exposed management services while you are in there.
What this means for South African businesses
SNMP is usually switched on for a reason: it is what Zabbix, The Dude and most monitoring stacks poll. That means the routers most likely to be exposed are exactly the ones a business believes are being watched, and many were enabled years ago with the default community and no source restriction.
The impact is loss of monitoring and an outage shaped like a reboot, not a breach, so the honest risk here is moderate. The reason to act this week is that an unauthenticated UDP service answering on a guest network is a standing invitation, and the fix is a single upgrade.
Source: MikroTik security advisory, 20 October 2026.
Also on the blog
- PHP CVE-2026-109618 and CVE-2026-109619: 9.2 RCE, patch due 14:00 UTC
- Plex Media Server CVE-2026-96656: exploited chain, CVSS 8.6
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.