Para quem administra uma rede corporativa, instalar uma atualização de segurança costuma ser o momento de encerrar uma vulnerabilidade e seguir para a próxima prioridade. O caso dos switches Zyxel GS1900 mostra por que essa confiança precisa ser acompanhada de verificação. Uma falha corrigida em junho parecia resolvida, mas a análise de uma ferramenta de ataque encontrada meses depois revelou que equipamentos já atualizados ainda podiam ser comprometidos por outra vulnerabilidade no mesmo componente de gerenciamento.
A nova falha, identificada como CVE-2026-107441, levou a Zyxel a disponibilizar uma segunda correção para dez modelos da família GS1900. A descoberta ganhou peso porque surgiu no contexto de uma investigação sobre ataques reais, não apenas de testes acadêmicos. Segundo informações divulgadas sobre a campanha acompanhada pela GreyNoise, 996 switches em 48 países foram atingidos, com coleta de arquivos de configuração, informações de rede e hashes de credenciais administrativas. Isso não significa que todos tenham sido invadidos especificamente por essa nova CVE: a associação técnica entre o código de exploração e a vulnerabilidade foi estabelecida posteriormente, durante a análise do material encontrado.
O impacto potencial vai além do próprio switch. Em muitas organizações, esses equipamentos guardam informações sobre VLANs, endereços de gerenciamento e a organização dos segmentos internos. Para um invasor, obter esses dados pode facilitar o reconhecimento da infraestrutura e a preparação de novos movimentos, mesmo quando o ataque inicial não provoca uma indisponibilidade perceptível. É por isso que a exposição de um equipamento de rede merece atenção semelhante à dedicada a servidores e sistemas de identidade.
O que a investigação revelou sobre as duas falhas
Em 16 de junho de 2026, a fabricante havia publicado uma atualização para a CVE-2026-7273, um estouro de buffer na pilha do componente CGI utilizado pela interface administrativa dos GS1900. O firmware 2.90 Patch 2 tratava aquela falha. Ocorre que pesquisadores da Binarly recuperaram um script Python ofuscado, associado a uma infraestrutura maliciosa investigada também por sua relação com o backdoor JITTERLY e o rootkit SIXZUT, e observaram que a técnica ainda funcionava em versões que já continham a atualização.
A análise apontou uma condição diferente: o tratamento inadequado de um contador de parâmetros antes da validação necessária permitia uma escrita fora dos limites de memória, com possibilidade de execução de comandos. Essa segunda vulnerabilidade recebeu o identificador CVE-2026-107441 e classificação CVSS v3.1 de 8,8, considerada alta. As duas CVEs atingem o mesmo componente e podem ter consequências semelhantes, mas não devem ser apresentadas como uma única falha que permaneceu aberta. A correção de junho tratou a primeira; a descoberta posterior mostrou que outra condição explorável ainda existia.
Também não há evidência suficiente para afirmar que os operadores desenvolveram o exploit especificamente para contornar o patch anterior. Ele pode ter explorado uma condição independente que já estava presente no software. A distinção parece pequena, mas é essencial para entender a eficácia das correções e evitar atribuir intenções ou capacidades que a investigação não demonstrou. A Binarly comunicou o problema à Zyxel em 29 de setembro, a fabricante confirmou a nova falha em outubro e publicou o aviso de segurança em 3 de novembro, após disponibilizar as compilações corrigidas.
Notícias Relacionadas
Há uma condição importante no alerta oficial: a Zyxel descreve a exploração como possível para um atacante sem autenticação, desde que tenha acesso à rede local e consiga alcançar o serviço de gerenciamento. Portanto, não é correto afirmar que todos os switches GS1900 estejam diretamente expostos à internet. O risco real depende da arquitetura adotada, da segmentação entre usuários e equipamentos administrativos e dos caminhos de acesso oferecidos por VPNs, prestadores de serviço ou estações que já tenham sido comprometidas.
Em uma rede pouco segmentada, por exemplo, a invasão de um computador de usuário pode permitir que o atacante alcance a interface de administração de um switch que deveria estar isolada. Se conseguir executar comandos, poderá buscar configurações e informações operacionais úteis para outras etapas do ataque. O acesso a hashes de senhas também não deve ser minimizado: dependendo das condições de armazenamento e reutilização das credenciais, esses dados podem aumentar a exposição de outros ativos.
A atualização é necessária, mas pode não ser suficiente
O aviso da Zyxel abrange os modelos GS1900-8, GS1900-8HP, GS1900-10HP, GS1900-16, GS1900-24, GS1900-24E, GS1900-24EP, GS1900-24HPv2, GS1900-48 e GS1900-48HPv2. As versões afetadas incluem o firmware 2.90 Patch 2 e anteriores; a correção está nas compilações 2.90 Patch 3 específicas de cada equipamento. Isso exige conferir o identificador completo indicado pelo fabricante, pois encontrar apenas a versão geral “2.90” no inventário não comprova que a vulnerabilidade foi corrigida.
Para as empresas, a primeira providência é localizar os switches em operação, inclusive em filiais, laboratórios e redes sob administração terceirizada. A atualização deve ser precedida de backup das configurações e executada em janela de manutenção, seguida de confirmação da versão instalada. Ao mesmo tempo, as interfaces administrativas precisam permanecer acessíveis somente a partir de estações e redes de gerenciamento autorizadas. Separar essas interfaces das VLANs de usuários e visitantes reduz a possibilidade de que um incidente em uma estação se transforme em acesso à infraestrutura de rede.
Existe, porém, uma questão que não se resolve apenas com a troca de firmware. Se um equipamento foi comprometido antes da atualização, informações já extraídas continuam nas mãos do invasor. Por isso, ambientes potencialmente atingidos devem examinar alterações de configuração, contas administrativas, serviços inesperados, registros disponíveis e padrões incomuns de comunicação. Também pode ser necessário substituir credenciais expostas e verificar outros dispositivos que compartilhem senhas ou práticas de administração. A falta de logs detalhados não é prova de que não houve invasão.
O episódio dos GS1900 deixa uma lição prática para a gestão de vulnerabilidades. Instalar a versão recomendada é uma etapa indispensável, mas não encerra automaticamente a análise de risco. É preciso saber se o equipamento realmente executa a compilação corrigida, quem consegue acessar sua administração e se existem indícios de atividade anterior. Para a área de segurança, o trabalho envolve inventário confiável, gestão de mudanças, segmentação de rede e investigação técnica — não apenas a conclusão de uma tarefa de atualização.
Be the first to comment