Nem todo CVE corrigido merece o mesmo nível de urgência. A maioria é "atualize na próxima janela de manutenção". A MikroTrick não é dessas: o CERT Polska (CERT.pl, o CSIRT nacional da Polônia) confirmou exploração ativa antes mesmo de existir correção — os ataques foram rastreados desde 2 de setembro de 2026, um dia antes da MikroTik publicar as versões corrigidas, em 3 de setembro. E o vetor de entrada é um dos serviços mais comuns de se deixar aberto em equipamento de provedor: SSH.
O que é a MikroTrick
A MikroTrick é uma cadeia de duas falhas que, combinadas, dão a um atacante sem nenhuma credencial controle administrativo completo do equipamento:
- CVE-2026-67276 — bypass de autenticação SSH: o RouterOS não compara a chave pública RSA completa ao validar uma tentativa de autenticação.
- CVE-2026-86060 — escalação de privilégio via nome de usuário malformado, que entrega acesso administrativo total depois do bypass inicial.
As duas foram exploradas juntas, sem exigir credencial válida nem interação do usuário. O CERT Polska coordenou a divulgação de seis vulnerabilidades no RouterOS ao todo (duas críticas — as que formam a MikroTrick); uma terceira, CVE-2026-67277, é uma falha relacionada mas separada, documentada à parte pela comunidade de pesquisa. Segundo a Shadowserver Foundation, mais de 122 mil instâncias de RouterOS com SSH exposto à internet foram identificadas — a superfície de ataque real por trás desse número.
Ficam protegidas as versões:
- RouterOS 7.25 beta 3 ou superior
- RouterOS 7.24.2 ou superior
- RouterOS 7.23.4 ou superior
- RouterOS 6.49.21 ou superior (linha legada)
Qualquer equipamento rodando versão anterior a essas, com SSH alcançável de rede não confiável, é candidato a alvo — não hipotético, ativo.
Checklist de mitigação
- Atualizar para a versão corrigida da sua branch agora, tratando como correção de emergência, não como patch de rotina.
- Tirar o SSH do alcance de rede não confiável. Se hoje ele responde na internet ou na rede de cliente, feche ou restrinja por firewall/allowlist imediatamente — antes até de atualizar, se a atualização não for possível na hora.
- Usar VPN (WireGuard é a recomendação mais citada pra RouterOS) pra gerência remota, em vez de abrir a porta de SSH direto.
- Verificar o status "Flagged" no equipamento após atualizar — é o indicador que a própria MikroTik associa a sinal de comprometimento prévio.
- Revisar configuração após a atualização, não só a versão instalada — uma exploração anterior à correção pode ter deixado alteração de configuração que o patch não desfaz sozinho.
Por que "só uma parte da frota" não é resposta suficiente
O padrão se repete a cada CVE crítico em equipamento de borda: a pergunta que trava o provedor não é "como corrijo", é "tenho certeza que corrigi todos". Numa operação com dezenas de roteadores MikroTik espalhados entre POPs, rádios e concentradores, confiar em "acho que já atualizamos a maioria" é exatamente o intervalo onde o equipamento esquecido — geralmente o mais antigo, o mais remoto, o que ninguém lembra de que ainda está em produção — segue exposto enquanto o resto da rede já está seguro.
Isso é mais gestão de inventário geolocalizado do que segurança propriamente dita: saber, por local físico, qual equipamento já recebeu qual versão. Se seu Zabbix já coleta versão de firmware por host mas o time ainda decide prioridade de patch por planilha ou por ordem alfabética, esse é o tipo de gap que aparece exatamente na hora que menos se pode esperar por ele — no meio de uma exploração ativa confirmada. Veja como o NOC Geomap cruza inventário com localização no mapa ou fale com a gente pra revisar isso antes do próximo CVE.
Fontes: MikroTik — September 2026 vulnerability (MikroTrick) e CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited.