Voltar à sala de imprensa
Ameaças

Um RCE do GitLab com CVSS 10 e um DoS em firewalls Cisco entram na lista de vulnerabilidades exploradas da CISA

A CISA adicionou ao catálogo KEV uma falha de execução remota de código de severidade máxima no GitLab e um defeito de negação de serviço no Cisco Secure Firewall, após confirmação de exploração. A falha do GitLab já foi testada contra a infraestrutura do Alpine Linux. Prazo de correção: 1 de novembro de 2026.

Um RCE do GitLab com CVSS 10 e um DoS em firewalls Cisco entram na lista de vulnerabilidades exploradas da CISA

Um RCE do GitLab com CVSS 10 e um DoS em firewalls Cisco entram na lista de vulnerabilidades exploradas da CISA

Duas novas vulnerabilidades entraram esta semana no catálogo Known Exploited Vulnerabilities (KEV) da CISA, e ambas exigem atenção imediata: uma falha de execução remota de código de severidade máxima no GitLab e um defeito de negação de serviço na linha Cisco Secure Firewall. As agências civis federais dos EUA têm até 1 de novembro de 2026 para aplicar as correções. Qualquer outra organização deve encarar essa data como uma referência razoável.

O que foi adicionado

  • CVE-2026-97229 (CVSS 10.0) – GitLab CE/EE. Um integer overflow (wraparound) na forma como o GitLab valida expressões regulares na configuração CI/CD. Um atacante não autenticado pode submeter uma definição de pipeline manipulada e executar código arbitrário diretamente no servidor GitLab.
  • CVE-2026-76418 (CVSS 8.6) – Cisco Secure Firewall ASA e FTD. Um valor de retorno não verificado conduz a uma desreferência de ponteiro NULL. Um atacante remoto, sem autenticação, pode forçar o reinício inesperado do equipamento e deixar a firewall fora de serviço.

A Cisco reconheceu que a falha da firewall já estava a ser explorada no início de outubro. Não foram divulgados detalhes sobre quem está por trás da atividade, quantas organizações foram visadas ou o que os atacantes fizeram depois de obterem acesso.

A falha do GitLab já foi testada no terreno

A entrada do GitLab está ligada a um incidente no Alpine Linux. A 20 e 21 de outubro, um ator não identificado visou a instância GitLab auto-alojada da distribuição, que ainda não tinha sido corrigida. O atacante submeteu configurações CI manipuladas que fizeram cair os processos worker do GitLab oito vezes; em quatro dessas tentativas, a cadeia de exploração falhou no passo seguinte. O mesmo ator descarregou ainda a imagem de contentor GitLab do projeto Alpine. As tentativas posteriores de voltar a entrar, a 25 e 26 de outubro, foram bloqueadas.

Os responsáveis pelo Alpine concluíram que o ataque esteve perto de resultar. Não encontraram provas de um comprometimento bem-sucedido, mas também não o puderam excluir, pelo que trataram o servidor como comprometido e reconstruíram-no de raiz. As verificações de integridade confirmaram que o repositório aports, a árvore de pacotes e as versões publicadas a 21 de outubro não tinham sido alteradas.

Porque é que isto importa

  • O GitLab é um ponto crítico da cadeia de fornecimento de software. Um RCE sem autenticação num servidor GitLab expõe de uma só vez o código-fonte, os segredos de CI, as chaves de assinatura e os pipelines de build. Mesmo uma tentativa falhada, como mostra o caso do Alpine, obriga a uma reconstrução dispendiosa e a uma revisão completa de integridade.
  • As firewalls são alvos de perímetro. Reinícios repetidos de um equipamento ASA/FTD interrompem a conectividade e o acesso VPN, e podem servir de distração ou de primeiro passo para outras atividades.
  • Estar no KEV significa exploração confirmada, não risco teórico. Vulnerabilidades com evidência de exploração ativa devem passar para o topo da fila de patches.

O que fazer

  1. Atualize o GitLab CE/EE para as versões corrigidas publicadas pelo GitLab. Se não puder aplicar o patch de imediato, limite quem pode submeter configurações CI e reveja os registos à procura de quedas invulgares dos processos worker entre 20 e 26 de outubro.
  2. Atualize o Cisco ASA e FTD e vigie reinícios inesperados dos equipamentos.
  3. Trate o GitLab auto-alojado como um ativo crítico: sem exposição direta à internet se não for indispensável, MFA para todos os utilizadores, registos de auditoria preservados e rotação dos segredos CI após qualquer atividade suspeita.
  4. Verifique a sua exposição. Inventarie as instâncias GitLab e as firewalls Cisco acessíveis a partir da internet e confirme as versões instaladas.

Servidores GitLab e interfaces de administração de firewalls expostos para o exterior são exatamente o tipo de problema que o nosso serviço de scanning de vulnerabilidades foi concebido para detetar: versões sem patch de produtos incluídos na lista KEV, sinalizadas antes de o prazo de correção começar a importar.

PARTILHAR