A SonicWall GMS (Global Management System) está no centro de um alerta de segurança que merece atenção imediata dos administradores de infraestrutura. A fabricante confirmou duas vulnerabilidades que afetam o software GMS 9.5.2 e versões anteriores, mas não disponibilizará atualizações para corrigir os problemas porque a plataforma já atingiu o estágio de End of Life (EOL).
As falhas envolvem dois riscos distintos: leitura não autenticada de arquivos internos e injeção de SQL após autenticação. Na prática, um invasor com acesso à interface de rede pode explorar a primeira vulnerabilidade sem precisar de credenciais, enquanto a segunda permite que usuários com privilégios específicos acessem ou modifiquem informações armazenadas no banco de dados da aplicação.
O alerta evidencia um problema recorrente na segurança corporativa: manter sistemas de gerenciamento antigos em operação mesmo depois do encerramento do suporte do fabricante. Para organizações que ainda dependem do SonicWall Global Management System, a recomendação é planejar a migração para o SonicWall Network Security Manager (NSM) e aplicar medidas de isolamento enquanto a substituição não acontece.
Falhas críticas no SonicWall GMS e os vetores de ataque
As duas vulnerabilidades foram identificadas por pesquisadores da Pentest-Tools, incluindo Matei Badanoiu e Andrei Lungu. Os problemas foram divulgados em 3 de novembro de 2026 e receberam identificadores próprios no catálogo CVE.
Embora afetem o mesmo produto, as falhas possuem requisitos de exploração e impactos diferentes. Essa distinção é importante para que as equipes de segurança estabeleçam prioridades e compreendam por que a exposição do servidor GMS representa um risco significativo.
Leitura não autorizada de arquivos internos
A primeira vulnerabilidade, identificada como CVE-2026-109593, permite que um atacante não autenticado, desde que consiga estabelecer comunicação de rede com o SonicWall GMS, leia arquivos internos da plataforma.
O problema recebeu classificação CVSS 3.1 de 9,1, considerada crítica. O principal agravante é a ausência de exigência de privilégios: o invasor não precisa conhecer uma senha válida ou possuir uma conta legítima para tentar explorar a falha.
Arquivos internos de uma aplicação de gerenciamento podem conter informações importantes para compreender a infraestrutura, identificar componentes utilizados e descobrir configurações que não deveriam estar disponíveis publicamente.
Dependendo do conteúdo acessível, a exposição pode revelar informações sensíveis sobre o ambiente operacional e facilitar etapas posteriores de um ataque. Credenciais, parâmetros de configuração e outros dados internos, caso estejam presentes nos arquivos acessíveis, podem ampliar as possibilidades de comprometimento.
É importante destacar que a descrição oficial da vulnerabilidade confirma a possibilidade de leitura de arquivos internos, mas não significa que todos os dados mencionados estejam necessariamente expostos em qualquer instalação.
O maior problema está na possibilidade de exploração sem autenticação. Se a interface de gerenciamento estiver acessível por redes não confiáveis, a superfície de ataque aumenta consideravelmente.
Injeção de SQL e manipulação de banco de dados
A segunda falha, registrada como CVE-2026-109594, envolve uma vulnerabilidade de SQL Injection, ou injeção de SQL.
Diferentemente da primeira, essa exploração exige autenticação e privilégios elevados. O problema recebeu pontuação CVSS 3.1 de 6,8, classificada como média.
A vulnerabilidade ocorre quando entradas controladas pelo usuário não são tratadas adequadamente antes de serem incorporadas a comandos SQL. Com isso, um invasor autorizado pode manipular a consulta enviada ao banco de dados, fazendo com que o sistema interprete instruções diferentes daquelas originalmente pretendidas pelos desenvolvedores.
No caso do SonicWall GMS, a falha pode permitir, em condições específicas, acesso ou modificação de informações armazenadas no banco de dados da plataforma.
Isso representa um risco para a confidencialidade e a integridade dos registros. Informações administrativas, dados operacionais e configurações armazenadas podem ser afetados, dependendo das permissões disponíveis e das condições de exploração.
A exigência de privilégios elevados não elimina o perigo. Contas comprometidas, credenciais reutilizadas ou acessos administrativos concedidos de maneira excessivamente permissiva podem oferecer aos invasores o ponto de partida necessário.
As duas vulnerabilidades demonstram por que proteger apenas as credenciais de acesso não é suficiente. A segurança também depende de aplicações atualizadas, serviços corretamente isolados e plataformas que ainda recebem manutenção do fabricante.
O perigo de manter softwares em fim de ciclo de vida
O aspecto mais preocupante desse alerta não é apenas a existência das vulnerabilidades, mas a ausência de uma correção prevista. O SonicWall GMS chegou ao fim de seu ciclo de vida, o que significa que a fabricante não fornecerá os patches necessários para eliminar os problemas identificados nas versões afetadas.
A situação exige uma mudança na maneira como as empresas tratam sistemas legados. Uma aplicação pode continuar funcionando normalmente durante anos, mas isso não significa que permaneça segura. Quando o fabricante encerra o suporte, novas vulnerabilidades podem surgir sem que exista uma atualização oficial para solucioná-las.
No caso do GMS, a SonicWall já havia iniciado a transição comercial para sua plataforma sucessora. O produto atingiu o marco de encerramento de novos pedidos em 1º de outubro de 2025, e a fabricante passou a direcionar seus clientes para o NSM.
O problema é particularmente relevante porque o GMS desempenhava uma função estratégica em ambientes corporativos: centralizar a administração de firewalls e outros dispositivos de segurança. Uma plataforma com esse nível de acesso pode representar um alvo valioso para invasores.
Se comprometido, um servidor de gerenciamento pode fornecer informações sobre a arquitetura da rede, os dispositivos administrados e as configurações de segurança. Dependendo das permissões e integrações existentes, o incidente também pode facilitar ataques contra outros componentes da infraestrutura.
O histórico de exploração de falhas da SonicWall aumenta a preocupação
A preocupação não é meramente teórica. Vulnerabilidades em produtos SonicWall já apareceram no catálogo Known Exploited Vulnerabilities (KEV) da CISA, agência de cibersegurança dos Estados Unidos.
O catálogo reúne falhas para as quais existem evidências de exploração real. Entre os registros relacionados à fabricante estão vulnerabilidades em dispositivos SMA1000 e em produtos que utilizam SonicOS.
Algumas dessas falhas também foram associadas a campanhas de ransomware. Em julho de 2026, por exemplo, vulnerabilidades nos dispositivos SMA1000 foram incluídas no catálogo KEV após a confirmação de exploração por criminosos.
É importante fazer uma distinção: isso não significa que as duas vulnerabilidades recém-divulgadas no GMS já estejam sendo exploradas. Até a divulgação do alerta, não há confirmação apresentada de exploração dessas duas falhas específicas.
Entretanto, o histórico demonstra que produtos de infraestrutura da fabricante podem ser alvos de operações criminosas. Manter uma plataforma sem suporte e com vulnerabilidades conhecidas representa um risco que não deve ser tratado como uma simples pendência de atualização.
Recomendações e plano de migração para o NSM
A principal recomendação é substituir o SonicWall GMS pelo Network Security Manager (NSM). Como não haverá correção para as vulnerabilidades anunciadas, atualizar componentes isolados ou modificar configurações da aplicação não elimina o problema estrutural.
O NSM é a plataforma indicada pela própria SonicWall para assumir as funções de gerenciamento centralizado. A solução oferece modalidades de implantação em nuvem e local, permitindo que as organizações avaliem qual arquitetura atende melhor às suas necessidades operacionais.
A migração, entretanto, exige planejamento. Simplesmente instalar a nova plataforma não garante que todos os dispositivos, políticas e processos administrativos estejam corretamente transferidos.
As equipes de infraestrutura devem organizar a substituição em etapas:
- Inventariar o ambiente: identificar todas as instalações do GMS, suas versões, servidores, dispositivos administrados, integrações e contas administrativas.
- Avaliar a compatibilidade: verificar quais firewalls e versões de firmware são suportados pelo NSM, considerando também os requisitos de licenciamento.
- Planejar a transição: definir a modalidade de implantação, os recursos necessários e os procedimentos para transferir o gerenciamento dos dispositivos.
- Validar as configurações: conferir políticas, permissões, registros, alertas e funcionalidades administrativas após a migração.
- Desativar o GMS antigo: retirar o servidor legado de operação depois de confirmar que os dispositivos estão sendo administrados corretamente pela nova plataforma.
Também é necessário observar as condições comerciais. As licenças do GMS e do NSM possuem modelos diferentes, e a elegibilidade para programas de transição pode depender da situação contratual e do suporte dos firewalls administrados.
Medidas paliativas enquanto a migração não acontece
Nem toda organização consegue substituir imediatamente uma plataforma de gerenciamento. Restrições orçamentárias, dependências operacionais e processos de aprovação podem prolongar a transição.
Isso não justifica manter o servidor vulnerável exposto. Enquanto a migração estiver em andamento, algumas medidas podem reduzir a superfície de ataque:
- Isolar o servidor em uma VLAN interna: restringir a comunicação aos segmentos estritamente necessários, impedindo que redes de usuários comuns alcancem a interface administrativa.
- Bloquear o acesso pela internet pública: remover qualquer publicação direta do GMS e revisar regras de firewall, NAT e encaminhamento de portas.
- Restringir os endereços de origem: permitir conexões somente a partir de estações administrativas e redes de gerenciamento previamente autorizadas.
- Reforçar o controle de contas: revisar usuários, remover contas desnecessárias, limitar privilégios e utilizar autenticação multifator quando disponível.
- Auditar os registros de acesso: procurar conexões inesperadas, tentativas de autenticação, atividades administrativas incomuns e acessos a arquivos ou recursos internos.
- Monitorar a infraestrutura: acompanhar alertas de segurança, tráfego de rede e eventuais alterações não autorizadas nos sistemas gerenciados.
Essas ações são medidas de contenção, não correções definitivas. O isolamento reduz as oportunidades de exploração, mas não torna o software seguro nem elimina as vulnerabilidades existentes.
Se houver suspeita de comprometimento, a equipe deve preservar os registros, investigar possíveis acessos indevidos e avaliar a necessidade de rotacionar credenciais que possam ter sido expostas.
Impacto na segurança corporativa e ações imediatas
O alerta envolvendo o SonicWall GMS reforça uma realidade importante para administradores de sistemas: softwares legados podem se transformar em pontos críticos de exposição quando continuam conectados à infraestrutura depois do encerramento do suporte.
A combinação de uma vulnerabilidade crítica sem autenticação, uma falha de injeção de SQL e a inexistência de patches torna especialmente arriscado manter versões antigas da plataforma em redes acessíveis por diferentes segmentos.
O problema também ultrapassa os limites do próprio servidor. Como o GMS centraliza atividades de gerenciamento, seu comprometimento pode fornecer informações estratégicas sobre outros dispositivos e facilitar a preparação de ataques mais amplos.
Por isso, a prioridade deve ser identificar todas as instalações afetadas, restringir imediatamente o acesso à plataforma e estabelecer um cronograma concreto de migração para o SonicWall NSM.
Adiar indefinidamente essa substituição significa aceitar um risco conhecido em um componente importante da infraestrutura de segurança. Para empresas que dependem de disponibilidade, confidencialidade e integridade dos ambientes corporativos, essa não é uma decisão operacional sustentável.
