A 30 de julho de 2026, a CISA publicou o aviso ICSA-26-211-01 sobre a CVE-2026-14227, uma falha na gestão de sessões da API do MikroTik RouterOS. A consequência reportada é suficientemente concreta para importar a quem aloja um túnel por conta própria: a chave privada WireGuard do router pode ser lida em texto simples a partir de uma sessão API que não devia ter esse nível de acesso.
A maior parte da cobertura ficou-se pelo título. O que decide o que deve fazer está mais abaixo.
Em que consiste a falha
O serviço API do RouterOS escuta na porta TCP 8728 sem cifra e na 8729 por TLS. A vulnerabilidade está classificada como expiração de sessão insuficiente: as sessões ativas mantêm as permissões que tinham ao abrir, pelo que reduzir os direitos de um utilizador ou deixar uma sessão expirar não produz necessariamente efeito numa ligação já estabelecida.
O resultado é um desalinhamento de privilégios. Uma sessão que devia ter sido despromovida continua a ler configuração que já não devia ver e, num router que termina um túnel WireGuard, essa configuração contém a chave privada estática.
Porque a pontuação engana
A gravidade publicada é moderada: CVSS 4.0 base 6,9 e CVSS 3.1 base 4,9 segundo a ficha da Rapid7. Vários meios chamaram-lhe crítica. Não é o que a pontuação diz, e repetir o adjetivo mais ruidoso não o ajudaria.
Mas ler o número como se fosse a história toda é o erro contrário. Uma pontuação CVSS mede a dificuldade de exploração e o alcance. Não mede a permanência da consequência. Uma falha classificada como média que expõe um token de sessão rotativo é uma tarde má. Uma falha classificada como média que expõe uma identidade criptográfica estática pertence a outra categoria de problema, porque a exposição não envelhece.

A parte que se salta: a chave não expira
Este é o cerne prático. No WireGuard, cada par possui um par de chaves estático, e é nessa identidade que o outro lado confia. Uma palavra-passe muda-se, um token expira, uma sessão morre. Uma chave privada guardada na configuração de um router não faz nada disso por si só.
Por isso a sequência que muitos seguem, desativar a API e dar o assunto por resolvido, fecha a porta sem trocar a fechadura. Se a chave era legível enquanto a API esteve exposta, desativar a API depois não a des-vaza. A rotação é o passo que restaura de facto a relação de confiança, e é o que mais se adia porque obriga a mexer em cada par.
O que o sigilo persistente cobre e o que não cobre
Vale a pena ser preciso, porque a expressão decifragem de todo o tráfego associado foi repetida por toda a parte e lê-se facilmente como pior do que é.
O handshake do WireGuard deriva chaves de sessão efémeras, o que dá ao protocolo o seu sigilo persistente. Um atacante que tenha a sua chave privada estática, e mais nada, não consegue decifrar retroativamente o tráfego que capturou antes. Essa propriedade mantém-se intacta.
O que a chave estática lhe dá é identidade. Pode apresentar-se como esse par, concluir handshakes e intercetar ativamente novas sessões. Na prática, isso significa personificação e interceção ativa daqui para a frente, não um arquivo legível do passado. É sério, mas é outra ameaça, e a distinção muda a sua resposta: não está a avaliar danos em tráfego antigo, está a revogar uma identidade.
O que fazer, por ordem
Determine se a API era sequer acessível. Se o serviço estava desativado, ou ligado apenas a uma interface que um atacante nunca poderia tocar, a sua exposição é teórica. Verifique antes de entrar em pânico e antes de reconstruir seja o que for.
Desative o serviço API se não precisar dele. É o contorno para o qual o aviso aponta e, numa instalação doméstica ou de administrador único, a API está frequentemente ativada sem alguma vez ser usada.
Termine a sessão dos utilizadores quando lhes reduzir direitos. A própria orientação da MikroTik é que um utilizador com permissões reduzidas tem de ficar completamente desligado para que a nova política se aplique. Merece entrar no seu procedimento, e não ser feito uma única vez, porque é exatamente o comportamento que a falha aproveita.
Rode as chaves se a exposição era plausível. Gere um novo par no router, atualize cada par com a nova chave pública e remova a antiga. É o passo maçador e o único que termina a exposição em vez de a suspender.
Não confie num intervalo de versões lido em segunda mão. A imprensa diz que todas as versões com a API ativada estão afetadas; a ficha da Rapid7 não indica intervalo algum. Verifique o seu próprio equipamento em vez de se dar por seguro porque um número num artigo não coincidia com o seu.
O ponto mais amplo para quem aloja por conta própria
Correr o seu próprio túnel significa que a chave vive em hardware que controla, o que é exatamente o atrativo e exatamente a exposição. A segurança de uma VPN auto-hospedada é a da máquina onde corre, incluindo as interfaces de administração que se esqueceu de que estavam à escuta.
Não é um argumento contra alojar por conta própria; é um argumento para tratar o plano de administração como parte da VPN. Se está a auditar a sua instalação, o nosso guia de resolução de problemas do handshake WireGuard explica como ler o estado dos pares, e o glossário de VPN auto-hospedada define os termos usados acima.
Em resumo
A CVE-2026-14227 está classificada como média e expõe algo que não expira. Verifique se a sua API era acessível, desative-a se não a usa, termine a sessão dos utilizadores quando os direitos mudarem, e rode a chave se a exposição era plausível. O sigilo persistente protege o seu tráfego passado; nada protege uma identidade que deixa no lugar depois de ter sido lida.
★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · 200+ Mbps garantidos
Tire o túnel do router para uma máquina que você administra → VPS ContaboUm VPS separa a VPN do firmware de um router doméstico e das suas interfaces de administração. Acesso root, preço previsível, datacenters europeus.→★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · 200+ Mbps garantidos
Aloje a sua VPN no seu próprio VPS → ContaboAcesso root completo · IPv4 público · escolha a sua região→


