A atualização do RouterOS apagou o firmware do modem LTE — e atualizar de novo não recupera sozinho
paulogaldino

Se você atualizou algum MikroTik com modem LTE nos últimos dois dias, é possível que o link de dados esteja fora — e que atualizar de novo não resolva sozinho.

A MikroTik publicou em 16 de setembro de 2026 duas versões de correção, 7.23.7 e 7.24.4, com a mesma linha na nota oficial: “prevent the modem firmware from being deleted” — impedir que o firmware do modem seja excluído.

⭐⭐ O defeito foi introduzido pelas versões anteriores, publicadas dois dias antes: a 7.24.3, do ramo stable, e a 7.23.6, do long-term. Nos equipamentos atingidos, a atualização apaga o firmware do modem e a interface LTE para de funcionar.

Neste artigo

Tabela com a linha do tempo das versões do RouterOS em setembro de 2026
Três dias e quatro versões: o defeito entrou no stable e no long-term, e a correção saiu nos dois no mesmo dia.

A linha do tempo: três dias, quatro versões

Pelas notas de versão publicadas no canal oficial de downloads da MikroTik:

  • 14 de setembro — RouterOS 7.24.3 (stable): corrige, entre outras coisas, duas falhas identificadas por CVE, e introduz o defeito do LTE;
  • 15 de setembro — RouterOS 7.23.6 (long-term): introduz o mesmo defeito;
  • 16 de setembro — RouterOS 7.24.4 (stable) e 7.23.7 (long-term): ambas com a mesma correção, e ambas com o procedimento de recuperação escrito na própria nota.

📌 A nota da versão corretiva diz explicitamente em qual versão o problema nasceu: no 7.24.4 está escrito “(introduced in 7.24.3)”; no 7.23.7, “(introduced in 7.23.6)”. O fabricante não deixou o diagnóstico implícito — e isso facilita saber se você está exposto.

Quais equipamentos foram citados por nome

A nota oficial lista os equipamentos afetados, e a lista é específica:

📌 RBSXTLTE3-7 · EC25-EU&KNe · EG25-G&KNe · EC25-EU&SXTsq · EG25-G&SXTsq

⚠️ Traduzindo para o campo: são as unidades SXT LTE e os kits com modems EC25/EG25 — o tipo de equipamento que o provedor costuma usar em link de contingência, ponto remoto e cliente rural. Não é o roteador do núcleo: é justamente o equipamento que fica longe e que ninguém visita sem necessidade.

⭐ E é aí que está o risco operacional. Um SXT LTE instalado em torre ou em telhado de cliente, que perde o modem depois de uma atualização remota, não volta com um reboot — e pode exigir deslocamento se não houver outro caminho de acesso ao equipamento.

Tabela com os equipamentos afetados e o procedimento de recuperação do firmware do modem
Os equipamentos citados na nota oficial e os três passos publicados pela MikroTik para recuperar o LTE.

Os três passos para voltar — atualizar não basta

A própria MikroTik publicou o procedimento, e ele tem uma armadilha: só atualizar não recupera o modem. Os passos, como estão na nota:

  • 1. atualizar o RouterOS para 7.23.7 ou 7.24.4;
  • 2. atualizar o firmware do modem: /interface/lte/firmware-upgrade [find] upgrade=yes;
  • 3. reiniciar o roteador.

⚠️⚠️ O passo 2 é o que a pressa costuma pular. A versão nova impede que o firmware seja excluído daqui para frente — ela não devolve o firmware que já foi apagado. Quem atualizar e concluir que “continua sem LTE, então não era isso” vai diagnosticar errado um problema que tem solução documentada.

O detalhe que muda a regra: desta vez o long-term não protegeu

Quando escrevemos sobre o RouterOS 7.24.1, que saiu sete dias depois do 7.24 para corrigir um defeito no WireGuard, a conclusão prática era a de sempre no setor: quem não quer sustos fica no ramo long-term e deixa o stable para quem precisa do recurso novo.

⭐⭐⭐ Este episódio quebra essa regra, e é o ponto mais importante deste texto. O defeito entrou no stable (7.24.3) e, um dia depois, no long-term (7.23.6). Quem seguia a recomendação conservadora foi atingido do mesmo jeito — com um dia de atraso.

📌 A leitura que sobra não é “abandone o long-term”. É outra: o ramo escolhe o seu apetite por recurso novo, não o seu risco de regressão. Contra regressão, o que protege é a janela de espera entre a publicação e a atualização — e ter um caminho de acesso ao equipamento que não dependa do que você acabou de atualizar.

O dilema real: a versão que quebrou trazia duas correções de segurança

Seria fácil concluir “não atualize”. O changelog do 7.24.3 não permite essa conclusão. Entre as dezenas de itens, dois são correções identificadas por CVE: crypto — improve stability (CVE-2026-67278) e user — improve failed login delay logic (CVE-2026-16347).

⚠️ Ou seja: a mesma versão que quebrou o LTE de cinco modelos fechou duas falhas. Adiar indefinidamente não é a decisão segura — é trocar um risco por outro.

É exatamente o tipo de decisão que já tratamos ao mostrar como o provedor separa o que importa em um mês com 27 avisos de segurança: a pergunta não é “atualizar ou não”, é “o que atualizo primeiro, e onde testo antes”.

📌 Neste caso concreto a resposta ficou simples, porque a correção existe: atualizar direto para 7.23.7 ou 7.24.4 entrega as correções de segurança sem o defeito do LTE. Quem ainda não atualizou pulou o problema inteiro.

O que o registro público diz das duas CVEs — e o changelog não diz

Fomos conferir as duas CVEs citadas no changelog no National Vulnerability Database do NIST, que é registro público e independente do fabricante. O que está lá muda a leitura da nota de versão.

  • CVE-2026-16347 — publicada no registro em 28 de julho de 2026, com nota CVSS 8.8, classificada como ALTA. A descrição: o RouterOS “contém uma fraqueza no tratamento da autenticação da API, sem salvaguardas efetivas contra tentativas excessivas de login” — sem limitação de taxa, sem bloqueio de conta e sem restrição por origem;
  • CVE-2026-67278 — publicada em 5 de setembro de 2026, nota CVSS 6.3, MÉDIA. O RouterOS “aceita assinaturas RSA/PKCS#1 v1.5 malformadas durante a validação X.509”, e como a lista de certificados confiáveis inclui uma autoridade com expoente 3, quem controlar ou redirecionar uma conexão TLS de saída do equipamento pode se aproveitar disso.

⭐⭐⭐ Agora compare com o que o provedor lê na nota de versão: a falha de nota 8,8 aparece como “user — improve failed login delay logic”, e a de 6,3 como “crypto — improve stability”. A linguagem do changelog não comunica gravidade nenhuma.

⚠️ E há a distância no tempo, que é um fato verificável: a CVE de nota alta está no registro público desde 28 de julho; a correção chegou ao RouterOS em 14 de setembro. São 48 dias em que a falha era pública e a versão corrigida não existia. Para a de setembro, foram 9 dias.

📌 A consequência prática para quem opera: acompanhar só o changelog é insuficiente para priorizar. É por isso que a decisão de atualizar não pode nascer da leitura da nota de versão sozinha — e é a mesma razão pela qual o regulamento de segurança cibernética da Anatel alcança o provedor de pequeno porte: tratar vulnerabilidade é obrigação de quem presta o serviço, não do fabricante.

O que fazer com isso

  • Levante se você tem algum dos cinco modelos citados e se algum deles foi atualizado em 14 ou 15 de setembro.
  • Se o LTE caiu depois da atualização, siga os três passos — e não pare no primeiro: sem o firmware-upgrade, o modem continua sem firmware.
  • Se ainda não atualizou, vá direto para 7.23.7 ou 7.24.4. As versões intermediárias não têm vantagem nenhuma agora.
  • Não use o ramo como política de risco. Desta vez o defeito entrou nos dois; o que protege é esperar alguns dias e testar em um equipamento acessível.
  • Garanta um caminho de acesso independente para equipamento remoto que só fala pelo LTE. É o caso em que a atualização derruba o próprio meio de gerenciar.
  • Não priorize pela linguagem do changelog. “Improve stability” pode ser uma falha de nota 8,8 — confira a CVE no registro público antes de decidir o que é urgente.
  • Leia a nota de versão antes de subir a atualização. Neste episódio, o fabricante escreveu o problema, os modelos e a solução — tudo no mesmo lugar.

O que este artigo não diz

  • Não testamos em equipamento. Tudo aqui vem das notas de versão oficiais da MikroTik, citadas literalmente.
  • Não sabemos quantos equipamentos foram afetados no Brasil, nem se há modelos além dos cinco citados na nota.
  • As notas das CVEs são as do NIST, no estado em que estavam na consulta: uma “Awaiting Analysis” e outra “Deferred”. Nota de CVSS é medida de severidade técnica, não de risco no seu ambiente.
  • Não medimos se as duas falhas foram exploradas contra provedores brasileiros. O registro público descreve a fraqueza, não o ataque.
  • O procedimento de recuperação é o do fabricante. Se ele não funcionar no seu caso, o caminho é o suporte da MikroTik, não a tentativa às cegas.
  • Versões mudam rápido. Este retrato é de 16 de setembro de 2026; confira sempre a nota da versão que você vai instalar.

Onde conferir

Fontes: as notas de versão oficiais, que trazem o defeito, os modelos e o procedimento.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *