---
title: "Duas falhas críticas permitem assumir roteadores MikroTik sem autenticação"
author: "Ignácio Afonso"
date: "2026-09-10 07:15:00-03"
category: "Segurança & Privacidade"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/10/duas-falhas-criticas-permitem-assumir-roteadores-mikrotik-sem-autenticacao/md"
---

## Resumo
- Duas falhas críticas do RouterOS, CVE-2026-67276 e CVE-2026-86060, permitem controle administrativo remoto sem autenticação.
- O CERT Polska classificou as vulnerabilidades com CVSS 9.2 e chamou a exploração combinada de MikroTrick.
- A exploração ativa foi observada desde 2 de setembro de 2026 e inclui contas suspeitas como "ops".
- O boletim da MikroTik recomenda não expor portas de gerenciamento à internet e usar VPN para acesso remoto.
- As correções estão disponíveis nas versões 7.25beta3, 7.24.2, 7.23.4 e 6.49.21 do RouterOS.
- Em caso de comprometimento, o dispositivo deve ser isolado antes do reset, com logs e configurações salvos para análise.
- Backups antigos podem carregar alterações maliciosas; após a limpeza, a recomendação é criar uma nova configuração baseada em fontes confiáveis.

---

Em setembro de 2026, pesquisadores do **CERT Polska** identificaram seis vulnerabilidades no RouterOS, sistema usado pelos roteadores MikroTik, e duas delas permitem combinar falhas de autenticação para assumir o controle administrativo do equipamento remotamente e sem autenticação. Os problemas receberam os códigos **CVE-2026-67276** e **CVE-2026-86060**, enquanto a exploração conjunta ganhou o nome de "MikroTrick". Como já existe exploração ativa contra dispositivos expostos à internet, o assunto deixou de ser uma simples atualização recomendada e passou a exigir verificação imediata de acesso, contas e configurações. A seguir, o caso é desbugado em ordem prática: o que as falhas fazem, quais versões corrigem o problema e como agir se houver indícios de comprometimento.

## O mecanismo por trás do MikroTrick

A história técnica do caso começa com duas falhas que atuam em pontos diferentes do processo de entrada no roteador. A **CVE-2026-67276** é descrita como um bypass de autenticação SSH, ou seja, uma falha na verificação das chaves RSA que deveria confirmar a identidade de quem tenta acessar o dispositivo. Já a **CVE-2026-86060** permite escalação de privilégios por meio de nomes de usuário manipulados, o que significa obter permissões superiores às que o sistema deveria conceder. Separadamente, cada problema já exige correção; combinados, eles formam a sequência que o CERT Polska chamou de "MikroTrick" e que transforma uma falha de entrada em controle administrativo.

Essa diferença entre as duas etapas ajuda a entender por que o alerta é tão severo. O CERT Polska atribuiu **CVSS 9.2** às duas vulnerabilidades, pontuação que indica a gravidade informada para os problemas, e descreveu a combinação como capaz de permitir a tomada remota do equipamento sem autenticação. A exploração ativa foi observada desde **2 de setembro de 2026**, com atividade associada ao endereço IP 82.192.72.4. Em outras palavras, não há apenas uma possibilidade teórica descrita em um boletim: existem sinais de tentativas contra roteadores que estavam acessíveis pela internet, o que conduz diretamente à necessidade de examinar os rastros deixados no aparelho.

## Os sinais que transformam o alerta em incidente

O risco deixa de ser abstrato quando aparecem alterações que o administrador não reconhece. Segundo os dados reunidos sobre a exploração, os invasores criaram contas suspeitas com nomes como **"ops"** em dispositivos afetados, e alguns equipamentos comprometidos podem apresentar o aviso **"Flagged status"** nos logs. Esses registros devem ser tratados como evidência para investigação, não como uma mensagem comum de operação, porque a combinação das vulnerabilidades permite chegar ao nível administrativo do roteador. A presença de um usuário desconhecido, portanto, conecta o defeito técnico a uma ação concreta dentro da configuração e indica que a atualização precisa vir acompanhada de inspeção.

O efeito prático dessa tomada de controle está ligado à forma como o roteador é administrado à distância. A recomendação oficial da [MikroTik em seu boletim de segurança](https://mikrotik.com/supportsec/september-2026-vulnerability) é não deixar portas de gerenciamento, como **SSH** e **WWW/WWW-SSL**, expostas a redes públicas e usar uma VPN para o acesso remoto. Essa orientação reduz a superfície diretamente alcançável por tentativas externas, mas não substitui a correção do sistema nem a busca por alterações já feitas. A piada é sem graça, mas precisa ser dita: se a porta de administração fica aberta para a internet, o problema deixa de estar escondido atrás da rede local e passa a receber visitas indesejadas.

## Correções disponíveis para o RouterOS

Além de confirmar a descoberta, a **MikroTik** informou que disponibilizou correções em todos os canais de atualização e comunicou o problema aos usuários do aplicativo da empresa. O aviso também trouxe um detalhe incomum: pela primeira vez, a companhia enviou uma **notificação push** para pessoas que tinham o aplicativo MikroTik instalado. A medida mostra a urgência atribuída ao caso, mas o alerta no celular não corrige sozinho o roteador. O administrador ainda precisa conferir a versão instalada, aplicar a atualização correspondente e revisar os serviços de gerenciamento que continuam acessíveis a partir de redes públicas.

Com a correção distribuída, o CERT Polska indicou as versões que já contêm os ajustes para os diferentes ramos do RouterOS: **7.25beta3, 7.24.2, 7.23.4 e 6.49.21**. A informação é especialmente relevante porque não existe uma única versão de destino para todos os equipamentos; o caminho depende do ramo utilizado pelo dispositivo. A [orientação do CERT Polska](https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/) também pede a verificação de usuários desconhecidos, scripts e tarefas de agendamento que não tenham sido criados pelo administrador. Atualizar, portanto, é o primeiro movimento, mas a conferência posterior procura alterações que uma simples troca de versão não necessariamente desfaz.

## O que fazer quando há indícios de invasão

Para quem administra um roteador com sinais de comprometimento, a ordem das ações precisa evitar a perda de evidências. O CERT Polska orienta que o dispositivo seja **isolado da rede antes do reset**, isto é, antes da restauração para as configurações de fábrica. Logs e configurações devem ser salvos para análise antes da limpeza, porque apagar o conteúdo primeiro pode remover justamente as informações que ajudam a entender quando o acesso ocorreu e o que foi alterado. A recomendação transforma o reset em uma etapa posterior, e não em uma reação automática assim que aparece uma conta desconhecida ou um aviso nos registros.

Depois dessa preservação, a restauração precisa ser acompanhada de uma decisão cuidadosa sobre os arquivos que voltarão ao equipamento. O CERT Polska alerta que **backups de configuração anteriores** podem ser perigosos se o dispositivo já tiver sido comprometido, pois eles podem carregar alterações feitas durante a invasão. A orientação é realizar uma nova configuração baseada em fontes confiáveis depois da limpeza, em vez de restaurar cegamente um arquivo antigo. Na prática, o administrador precisa conferir usuários, regras e rotinas autorizadas novamente, mantendo a reconstrução alinhada às recomendações do fabricante e às versões corrigidas do RouterOS.

## A sequência prática para fechar a porta

Essa sequência organiza a resposta sem misturar correção com investigação. Primeiro, o responsável deve identificar a versão do RouterOS e aplicar uma das versões corrigidas indicadas pelo CERT Polska; depois, precisa fechar as portas de gerenciamento voltadas à internet e reservar o acesso remoto para uma **VPN**. Em seguida, deve procurar contas, scripts e tarefas de agendamento desconhecidos, prestando atenção especial a nomes como "ops" e ao aviso "Flagged status" nos logs. Se houver evidência de comprometimento, o dispositivo deve ser isolado, os registros e as configurações precisam ser preservados e só então a restauração deve ser planejada.

O próximo passo para qualquer administrador de **roteador MikroTik** exposto é conferir imediatamente a versão instalada e a forma como o gerenciamento remoto está publicado, sem esperar que uma nova notificação apareça. A correção disponibilizada pela empresa resolve as vulnerabilidades conhecidas, enquanto o fechamento das portas públicas reduz novas tentativas; a inspeção de contas e rotinas verifica se o aparelho já foi alterado. Quando houver sinais concretos de invasão, a prioridade passa a ser preservar os dados, isolar o equipamento e reconstruí-lo com uma configuração nova e confiável, em vez de simplesmente reaproveitar um backup antigo.