6 de setembro de 2026 · Security-Advisory · SonicWall · Perimeter · Schwachstellenmanagement

SonicWall SMA1000: falhas críticas, sob exploração ativa

Duas vulnerabilidades no SonicWall SMA1000, uma com CVSS 10.0, estão sob exploração ativa. Versões afetadas, os hotfixes e porque aplicar o patch não chega.

A 1 de setembro de 2026, a SonicWall publicou hotfixes para duas vulnerabilidades nas suas appliances SMA1000. Um dia depois, o CERT-AT alertou: ambas já estão sob exploração ativa, e o próprio PSIRT do fabricante observa essa exploração. Não existe solução alternativa – apenas o hotfix.

A mais grave das duas tem uma pontuação CVSS de 10.0. É o valor máximo, e raramente é atribuído.

As duas vulnerabilidades

CVE-2026-83548 é um server-side request forgery na interface Work Place, avaliado com CVSS 10.0. O fabricante classifica-o como uma função de proxy não intencional (CWE-441); pode ser desencadeado sem autenticação prévia.

CVE-2026-83549 é uma injeção de comandos com CVSS 7.8. O CERT-AT descreve-a como uma vulnerabilidade que afeta administradores autenticados – isoladamente, portanto, a bem mais inofensiva das duas.

O perigoso é a combinação. Os relatos especializados descrevem que as duas podem ser encadeadas: a CVE-2026-83548 dá acesso não autenticado a funcionalidade com a qual se explora em seguida a CVE-2026-83549, executando comandos do sistema operativo sem autenticação prévia. Esse encadeamento vem da imprensa especializada, não do texto do CERT-AT, que apresenta a segunda falha, por si só, como ligada a administradores. Para a priorização isso não muda nada: uma das duas é, de qualquer modo, não autenticada e está avaliada com 10.0.

Quem é afetado

São afetados os modelos 6210, 7210 e 8200v nestas versões:

  • 12.4.3-03453 (platform-hotfix) e anteriores
  • 12.5.0-02835 (platform-hotfix) e anteriores

As versões corrigidas são:

  • 12.4.3-03526 (platform-hotfix) e posteriores
  • 12.5.0-02952 (platform-hotfix) e posteriores

Uma precisão que não queremos poupar: a SMA1000 é a maior das duas linhas SMA da SonicWall e foi durante muito tempo a variante empresarial. Isso mudou. A série SMA 100, mais pequena, atingiu antecipadamente o fim de suporte a 31 de outubro de 2025; a SonicWall anunciou que desativaria os equipamentos nessa data e remeteu os clientes para a sua solução na nuvem, o Cloud Secure Edge. Com isso, a SMA 1000 é a única linha de appliances SMA que resta – quem quis manter o caminho da appliance foi parar a ela.

Quantas médias empresas alemãs seguiram realmente esse caminho não é possível comprovar – é um mecanismo plausível, não uma prova, e os números de exposição publicados vêm de fornecedores diferentes, com critérios de contagem diferentes, e não são comparáveis entre si. Verifique-o, pois, no seu próprio inventário em vez de confiar numa categoria de dimensão. Se não opera nenhuma SMA1000, a primeira parte deste artigo está resolvida para si. A segunda não.

O que fazer agora

  • Aplicar o hotfix sem esperar por uma janela de manutenção. Não há solução alternativa e a exploração está em curso. Quão urgente é, mostra-o um olhar do outro lado do Atlântico: a agência norte-americana CISA incluiu ambas as falhas no seu catálogo de vulnerabilidades exploradas conhecidas a 2 de setembro e fixou às agências federais um prazo até 5 de setembro.
  • Determinar o build exato, não o ramo de versão. «Estamos na 12.4.3» não responde à pergunta – a diferença que conta está precisamente entre -03453 e -03526.
  • Partir de um possível comprometimento anterior ao patch. O hotfix fecha a falha; não desfaz o que possa ter acontecido antes. Verifique a configuração, as contas criadas e os registos à procura de anomalias – a SonicWall oferece expressamente para isso o apoio do seu próprio suporte.
  • Renovar credenciais e sessões. A SonicWall exige-o no seu próprio aviso para o caso de se encontrarem indícios de comprometimento: alterar todas as palavras-passe de utilizador e de administrador, repor os tokens TOTP e reinstalar a appliance. O CERT-AT não retoma este ponto. Nós recomendamos a mudança de palavras-passe e tokens mesmo sem achado – quem entra por um gateway VPN chega às credenciais; um equipamento com patch mas com credenciais ainda válidas está saneado apenas pela metade.
  • Rever a exposição. As interfaces de administração não pertencem à internet, nem sequer «temporariamente».
  • Esclarecer a situação de notificação. Se estiver abrangido pela NIS2 e uma suspeita se confirmar, desse achado depende um prazo.

Se, por motivos operacionais, a instalação não for imediatamente possível, resta apenas reduzir a acessibilidade: limitar o acesso ao portal a redes de origem conhecidas, desligar os serviços da appliance que não sejam necessários e vigiar de perto as tentativas de início de sessão. Isso não substitui o hotfix nem é uma solução alternativa no sentido do fabricante – apenas estreita a janela. Planeie a instalação em paralelo, não depois.

Porque aplicar o patch não chega

Esta frase não é preciso aceitá-la sem mais – vem do relatório de situação do BSI de 2025: «Em caso de exploração de vulnerabilidades, aplicar o patch por si só não costuma bastar para voltar a operar os equipamentos com segurança». No relatório de 2024 isso era ainda a exceção – aí dizia-se que em casos isolados aplicar o patch não basta. Um ano depois, tornou-se a regra.

A razão está na construção destes equipamentos. O BSI já a descreveu no relatório de 2024: os métodos de registo e de deteção de ataques em sistemas de perímetro estão «em parte limitados ou não são habituais», de modo que os ataques «não são tão detetáveis como, por exemplo, em sistemas cliente». Os atacantes instalam aí tipicamente web shells que esperam passivamente por uma ligação vinda de fora – possível «porque os sistemas de perímetro são, por definição, acessíveis a partir da internet».

Com isso, um gateway VPN fica no ponto mais desfavorável da rede: no máximo de exposição e no mínimo de observação. Num portátil corre uma deteção de endpoint que reporta comportamentos suspeitos. Numa appliance fechada, por regra, não corre nada disso. Quem só olha para lá depois do patch já não tem, muitas vezes, dados onde olhar.

Na prática decorrem daí três coisas. Primeira: os equipamentos de perímetro pertencem ao inventário, com versão e responsável – não à categoria «funciona há anos». Segunda: os seus registos devem sair da appliance para um sistema central enquanto ainda existem. E terceira: depois de um incidente neste ponto, a pergunta não é «está com patch?», mas «o que foi possível entre a divulgação e o patch, e como o excluímos?».

A tendência de ataques a sistemas de perímetro mantém-se, na avaliação do BSI. Este aviso não é, portanto, um caso isolado, mas um padrão – e preparar-se para ele é o verdadeiro trabalho.

Como a sector7 apoia

Para os ambientes que acompanhamos, mantemos o registo das versões e do ciclo de vida dos componentes de rede e de segurança e verificamos a superfície de ataque acessível a partir do exterior em análises recorrentes – para que a pergunta «estamos afetados?» não seja feita pela primeira vez no dia do aviso. Perante falhas sob exploração ativa assumimos, nesses ambientes, a instalação controlada ao longo das localizações, por etapas e com um caminho de retorno definido, e verificamos no mesmo movimento se há vestígios de um comprometimento anterior. Mais sobre isso em Cibersegurança e Redes e conectividade.

Fontes

Vamos falar sobre a sua situação.

Agendar uma conversa+49 212 240915 0