A CISA incluiu em 29 de outubro duas falhas no catálogo de vulnerabilidades com exploração conhecida: CVE-2026-97229, do GitLab, e CVE-2026-76418, do Cisco ASA/FTD. Para o provedor que usa essas plataformas, a tarefa é identificar a exposição real, priorizar a correção e verificar se o serviço continua funcionando depois dela. A inclusão não comprova que a rede do seu ISP foi atacada.
São problemas distintos: no GitLab, o risco descrito é execução de código no servidor; nos produtos Cisco afetados, é indisponibilidade. Não são novas falhas de PHP nem do kernel Linux. A novidade desta rodada é a inclusão no KEV, não a descoberta dos problemas.
GitLab: comece pelas instalações administradas pelo provedor
O aviso do GitLab, publicado em 12 de outubro, descreve execução de código por um usuário não autenticado, em determinadas condições, por meio de expressão regular especialmente preparada em uma configuração de CI/CD.
As faixas afetadas são GitLab CE/EE 19.2 anteriores à 19.2.8; 19.3 anteriores à 19.3.5; e 19.4 anteriores à 19.4.2. Essas são versões que receberam a correção citada, não uma recomendação de abandonar uma versão mais recente. Confira o caminho de atualização e o patch atual da sua série.
GitLab.com e GitLab Dedicated já estavam corrigidos segundo o aviso. Isso não atualiza automaticamente uma instalação self-managed do provedor ou de seu prestador. O fabricante também disponibiliza regras de detecção: elas ajudam a investigar tentativas, mas não substituem o patch.
O projeto Ruby explica que as correções relacionadas tratam da compilação de expressões regulares controladas por um atacante. Não se deve concluir que toda aplicação Ruby está exposta. O uso de timeout para expressões regulares não resolve esses problemas de compilação.
Cisco: versão e configuração precisam ser conferidas juntas
O aviso da Cisco, de 28 de outubro, trata de ASA e FTD em versões vulneráveis, com serviço de acesso remoto SSL VPN alcançável e autenticação secundária nas condições de grupo de túnel descritas pelo fabricante. Uma requisição pode provocar reinicialização e interrupção do serviço; não exige login bem-sucedido.
A Cisco informou conhecimento de exploração ativa em outubro e recomenda atualização para software corrigido. O administrador deve consultar a tabela do aviso e o Software Checker para sua família, versão e caminho de upgrade, em vez de aplicar um número genérico a todos os equipamentos.
Atenção ao grupo padrão DefaultWEBVPNGroup: esconder a lista de perfis não elimina a exposição quando esse grupo usa autenticação secundária. Não desative autenticação secundária ou MFA indiscriminadamente para “resolver” o alerta. A própria Cisco alerta que mitigação desse tipo pode reduzir a segurança e exige avaliação do ambiente. Correção e mitigação temporária não são a mesma coisa.
Checklist para abrir e concluir a mudança
1. Identifique quem administra cada instalação, inclusive fornecedores. Registre produto, versão efetivamente em execução e responsável, sem enviar senhas ou configurações sensíveis em grupos de mensagens.
2. Compare a instalação com as condições do aviso correspondente. Separe “não usamos o produto”, “usamos, mas falta verificar”, “exposto” e “corrigido com evidência”. Ausência no inventário não prova ausência na rede.
3. Priorize sistemas expostos e funções cuja interrupção comprometeria a operação. Mapeie dependências de autenticação, acesso remoto e automação antes de definir a janela.
4. Prepare backup, procedimento de restauração e plano de retorno compatíveis com o fabricante. Valide a atualização em ambiente adequado, sem reproduzir ataques contra sistemas de terceiros.
5. Execute a mudança autorizada e confirme a versão instalada. Teste o acesso remoto legítimo, a autenticação esperada e os fluxos de trabalho usados pela equipe. Um comando concluído sem erro não demonstra que a operação inteira está saudável.
6. Examine registros e detecções pertinentes. Se houver indícios de comprometimento, preserve evidências e acione o responsável pela resposta a incidentes; instalar o patch não explica nem elimina, por si só, uma invasão anterior.
7. Feche o chamado somente com responsável, horário, versão anterior e posterior, testes realizados e pendências registradas. Se um fornecedor opera o sistema, peça evidência da correção, não apenas “já resolvido”.
O prazo americano não é um prazo regulatório brasileiro
Os registros do KEV indicam 1º de novembro de 2026 como prazo de remediação no contexto federal civil americano. Isso não cria uma obrigação regulatória com essa data para provedores brasileiros. A exploração conhecida, porém, é um sinal para priorização técnica, conforme a exposição e a criticidade de cada ambiente.
Conferência editorial: 29 de outubro de 2026. Consulte os avisos originais antes da execução: versões recomendadas e orientações podem ser atualizadas. Este roteiro não identifica comprometimento em um provedor específico nem substitui a avaliação de sua equipe técnica.
